postgresql/src/backend/replication
Andres Freund fc49e24fa6 Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.

But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.

This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured.  For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.

Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
    Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-19 22:03:48 -07:00
..
libpqwalreceiver Fix up some misusage of appendStringInfo() and friends 2017-08-15 23:34:39 -04:00
logical Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00
pgoutput Message style fixes 2017-09-11 11:21:27 -04:00
.gitignore Support multiple synchronous standby servers. 2016-04-06 17:18:25 +09:00
Makefile Rethink flex flags for syncrep_scanner.l. 2017-05-19 18:05:20 -04:00
README Rename "pg_xlog" directory to "pg_wal". 2016-10-20 11:32:18 -04:00
basebackup.c Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00
repl_gram.y Add a WAIT option to DROP_REPLICATION_SLOT 2017-09-01 13:44:14 +02:00
repl_scanner.l Add a WAIT option to DROP_REPLICATION_SLOT 2017-09-01 13:44:14 +02:00
slot.c Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00
slotfuncs.c Add a WAIT option to DROP_REPLICATION_SLOT 2017-09-01 13:44:14 +02:00
syncrep.c Final pgindent + perltidy run for v10. 2017-08-14 17:29:33 -04:00
syncrep_gram.y Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
syncrep_scanner.l Rethink flex flags for syncrep_scanner.l. 2017-05-19 18:05:20 -04:00
walreceiver.c Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00
walreceiverfuncs.c Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00
walsender.c Make WAL segment size configurable at initdb time. 2017-09-19 22:03:48 -07:00

README

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_wal), 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.