mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 07:33:22 +02:00
4a9c30a8a1
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to create an fsync pending-operations table in the current process. This led to creating a table not only in the startup and checkpointer processes as intended, but also in the bgwriter process, not to mention other auxiliary processes such as walwriter and walreceiver. Creation of the table in the bgwriter is fatal, because it absorbs fsync requests that should have gone to the checkpointer; instead they just sit in bgwriter local memory and are never acted on. So writes performed by the bgwriter were not being fsync'd which could result in data loss after an OS crash. I think there is no live bug with respect to walwriter and walreceiver because those never perform any writes of shared buffers; but the potential is there for future breakage in those processes too. To fix, make AuxiliaryProcessMain() export the current process's AuxProcType as a global variable, and then make mdinit() test directly for the types of aux process that should have a pendingOpsTable. Having done that, we might as well also get rid of the random bool flags such as am_walreceiver that some of the aux processes had grown. (Note that we could not have fixed the bug by examining those variables in mdinit(), because it's called from BaseInit() which is run by AuxiliaryProcessMain() before entering any of the process-type-specific code.) Back-patch to 9.2, where the problem was introduced by the split-up of bgwriter and checkpointer processes. The bogus pendingOpsTable exists in walwriter and walreceiver processes in earlier branches, but absent any evidence that it causes actual problems there, I'll leave the older branches alone. |
||
|---|---|---|
| .. | ||
| libpqwalreceiver | ||
| .gitignore | ||
| basebackup.c | ||
| Makefile | ||
| README | ||
| repl_gram.y | ||
| repl_scanner.l | ||
| syncrep.c | ||
| walreceiver.c | ||
| walreceiverfuncs.c | ||
| walsender.c | ||
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. bool walrcv_receive(int timeout, unsigned char *type, char **buffer, int *len) Retrieve any message available through the connection, blocking for maximum of 'timeout' ms. If a message was successfully read, returns true, otherwise false. On success, a pointer to the message payload is stored in *buffer, length in *len, and the type of message received in *type. The returned buffer is valid until the next call to walrcv_* functions, the caller should not attempt freeing 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 receiveing WAL. Walreceiver IPC --------------- When the WAL replay in startup process has reached the end of archived WAL, recoverable using recovery_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 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 either it 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 walsenders will look like a regular backends 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.