Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

replication

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Alvaro Herrera authored
    There are two problems in the original coding: one is that if one
    walreceiver process exits, the ready_to_display flag remains set in
    shared memory, exposing the conninfo of the next walreceiver before
    obfuscating.  Fix by having WalRcvDie reset the flag.
    
    Second, the sleep-and-retry behavior that waited until walreceiver had
    set ready_to_display wasn't liked; the preference is to have it return
    no data instead, so let's do that.
    
    Bugs in 9ed551e0 reported by Fujii Masao and Michël Paquier.
    
    Author: Michaël Paquier
    1bdae16f
    History
    src/backend/replication/README
    
    Walreceiver - libpqwalreceiver API
    ----------------------------------
    
    The transport-specific part of walreceiver, responsible for connecting to
    the primary server, receiving WAL files and sending messages, is loaded
    dynamically to avoid having to link the main server binary with libpq.
    The dynamically loaded module is in libpqwalreceiver subdirectory.
    
    The dynamically loaded module implements four functions:
    
    
    bool walrcv_connect(char *conninfo, XLogRecPtr startpoint)
    
    Establish connection to the primary, and starts streaming from 'startpoint'.
    Returns true on success.
    
    int walrcv_receive(char **buffer, pgsocket *wait_fd)
    
    Retrieve any message available without blocking through the
    connection.  If a message was successfully read, returns its
    length. If the connection is closed, returns -1.  Otherwise returns 0
    to indicate that no data is available, and sets *wait_fd to a socket
    descriptor which can be waited on before trying again.  On success, a
    pointer to the message payload is stored in *buffer. The returned
    buffer is valid until the next call to walrcv_* functions, and the
    caller should not attempt to free it.
    
    void walrcv_send(const char *buffer, int nbytes)
    
    Send a message to XLOG stream.
    
    void walrcv_disconnect(void);
    
    Disconnect.
    
    
    This API should be considered internal at the moment, but we could open it
    up for 3rd party replacements of libpqwalreceiver in the future, allowing
    pluggable methods for receiving WAL.
    
    Walreceiver IPC
    ---------------
    
    When the WAL replay in startup process has reached the end of archived WAL,
    restorable using restore_command, it starts up the walreceiver process
    to fetch more WAL (if streaming replication is configured).
    
    Walreceiver is a postmaster subprocess, so the startup process can't fork it
    directly. Instead, it sends a signal to postmaster, asking postmaster to launch
    it. Before that, however, startup process fills in WalRcvData->conninfo
    and WalRcvData->slotname, and initializes the starting point in
    WalRcvData->receiveStart.
    
    As walreceiver receives WAL from the master server, and writes and flushes
    it to disk (in pg_xlog), it updates WalRcvData->receivedUpto and signals
    the startup process to know how far WAL replay can advance.
    
    Walreceiver sends information about replication progress to the master server
    whenever it either writes or flushes new WAL, or the specified interval elapses.
    This is used for reporting purpose.
    
    Walsender IPC
    -------------
    
    At shutdown, postmaster handles walsender processes differently from regular
    backends. It waits for regular backends to die before writing the
    shutdown checkpoint and terminating pgarch and other auxiliary processes, but
    that's not desirable for walsenders, because we want the standby servers to
    receive all the WAL, including the shutdown checkpoint, before the master
    is shut down. Therefore postmaster treats walsenders like the pgarch process,
    and instructs them to terminate at PM_SHUTDOWN_2 phase, after all regular
    backends have died and checkpointer has issued the shutdown checkpoint.
    
    When postmaster accepts a connection, it immediately forks a new process
    to handle the handshake and authentication, and the process initializes to
    become a backend. Postmaster doesn't know if the process becomes a regular
    backend or a walsender process at that time - that's indicated in the
    connection handshake - so we need some extra signaling to let postmaster
    identify walsender processes.
    
    When walsender process starts up, it marks itself as a walsender process in
    the PMSignal array. That way postmaster can tell it apart from regular
    backends.
    
    Note that no big harm is done if postmaster thinks that a walsender is a
    regular backend; it will just terminate the walsender earlier in the shutdown
    phase. A walsender will look like a regular backend until it's done with the
    initialization and has marked itself in PMSignal array, and at process
    termination, after unmarking the PMSignal slot.
    
    Each walsender allocates an entry from the WalSndCtl array, and tracks
    information about replication progress. User can monitor them via
    statistics views.
    
    
    Walsender - walreceiver protocol
    --------------------------------
    
    See manual.