• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

libpqwalreceiver/H08-Nov-2021-1,092703

logical/H08-Nov-2021-14,9508,498

pgoutput/H08-Nov-2021-694434

.gitignoreH A D08-Nov-202164 54

MakefileH A D08-Nov-2021975 3310

READMEH A D08-Nov-20214.1 KiB10273

basebackup.cH A D08-Nov-202147.1 KiB1,7711,091

repl_gram.cH A D08-Nov-202158.5 KiB1,9771,366

repl_gram.yH A D08-Nov-20218.6 KiB425332

repl_scanner.cH A D08-Nov-202167.8 KiB2,5631,779

repl_scanner.lH A D08-Nov-20214.9 KiB254180

slot.cH A D08-Nov-202143.5 KiB1,589880

slotfuncs.cH A D08-Nov-202124.4 KiB859509

syncrep.cH A D08-Nov-202139 KiB1,369708

syncrep_gram.cH A D08-Nov-202146.9 KiB1,5881,013

syncrep_gram.yH A D08-Nov-20212.9 KiB11770

syncrep_scanner.cH A D08-Nov-202152.4 KiB2,1641,405

syncrep_scanner.lH A D08-Nov-20213.2 KiB164115

walreceiver.cH A D08-Nov-202142.9 KiB1,492872

walreceiverfuncs.cH A D08-Nov-20218.4 KiB362208

walsender.cH A D08-Nov-2021101.9 KiB3,6461,977

README

1src/backend/replication/README
2
3Walreceiver - libpqwalreceiver API
4----------------------------------
5
6The transport-specific part of walreceiver, responsible for connecting to
7the primary server, receiving WAL files and sending messages, is loaded
8dynamically to avoid having to link the main server binary with libpq.
9The dynamically loaded module is in libpqwalreceiver subdirectory.
10
11The dynamically loaded module implements four functions:
12
13
14bool walrcv_connect(char *conninfo, XLogRecPtr startpoint)
15
16Establish connection to the primary, and starts streaming from 'startpoint'.
17Returns true on success.
18
19int walrcv_receive(char **buffer, pgsocket *wait_fd)
20
21Retrieve any message available without blocking through the
22connection.  If a message was successfully read, returns its
23length. If the connection is closed, returns -1.  Otherwise returns 0
24to indicate that no data is available, and sets *wait_fd to a socket
25descriptor which can be waited on before trying again.  On success, a
26pointer to the message payload is stored in *buffer. The returned
27buffer is valid until the next call to walrcv_* functions, and the
28caller should not attempt to free it.
29
30void walrcv_send(const char *buffer, int nbytes)
31
32Send a message to XLOG stream.
33
34void walrcv_disconnect(void);
35
36Disconnect.
37
38
39This API should be considered internal at the moment, but we could open it
40up for 3rd party replacements of libpqwalreceiver in the future, allowing
41pluggable methods for receiving WAL.
42
43Walreceiver IPC
44---------------
45
46When the WAL replay in startup process has reached the end of archived WAL,
47restorable using restore_command, it starts up the walreceiver process
48to fetch more WAL (if streaming replication is configured).
49
50Walreceiver is a postmaster subprocess, so the startup process can't fork it
51directly. Instead, it sends a signal to postmaster, asking postmaster to launch
52it. Before that, however, startup process fills in WalRcvData->conninfo
53and WalRcvData->slotname, and initializes the starting point in
54WalRcvData->receiveStart.
55
56As walreceiver receives WAL from the master server, and writes and flushes
57it to disk (in pg_wal), it updates WalRcvData->receivedUpto and signals
58the startup process to know how far WAL replay can advance.
59
60Walreceiver sends information about replication progress to the master server
61whenever it either writes or flushes new WAL, or the specified interval elapses.
62This is used for reporting purpose.
63
64Walsender IPC
65-------------
66
67At shutdown, postmaster handles walsender processes differently from regular
68backends. It waits for regular backends to die before writing the
69shutdown checkpoint and terminating pgarch and other auxiliary processes, but
70that's not desirable for walsenders, because we want the standby servers to
71receive all the WAL, including the shutdown checkpoint, before the master
72is shut down. Therefore postmaster treats walsenders like the pgarch process,
73and instructs them to terminate at PM_SHUTDOWN_2 phase, after all regular
74backends have died and checkpointer has issued the shutdown checkpoint.
75
76When postmaster accepts a connection, it immediately forks a new process
77to handle the handshake and authentication, and the process initializes to
78become a backend. Postmaster doesn't know if the process becomes a regular
79backend or a walsender process at that time - that's indicated in the
80connection handshake - so we need some extra signaling to let postmaster
81identify walsender processes.
82
83When walsender process starts up, it marks itself as a walsender process in
84the PMSignal array. That way postmaster can tell it apart from regular
85backends.
86
87Note that no big harm is done if postmaster thinks that a walsender is a
88regular backend; it will just terminate the walsender earlier in the shutdown
89phase. A walsender will look like a regular backend until it's done with the
90initialization and has marked itself in PMSignal array, and at process
91termination, after unmarking the PMSignal slot.
92
93Each walsender allocates an entry from the WalSndCtl array, and tracks
94information about replication progress. User can monitor them via
95statistics views.
96
97
98Walsender - walreceiver protocol
99--------------------------------
100
101See manual.
102