database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Add --synchronous option to pg_receivexlog, for more reliable WAL writing.

Browse Source 
Previously pg_receivexlog flushed WAL data only when WAL file was switched.
Then 3dad73e added -F option to pg_receivexlog so that users could control
how frequently sync commands were issued to WAL files. It also allowed users
to make pg_receivexlog flush WAL data immediately after writing by
specifying 0 in -F option. However feedback messages were not sent back
immediately even after a flush location was updated. So even if WAL data
was flushed in real time, the server could not see that for a while.

This commit removes -F option from and adds --synchronous to pg_receivexlog.
If --synchronous is specified, like the standby's wal receiver, pg_receivexlog
flushes WAL data as soon as there is WAL data which has not been flushed yet.
Then it sends back the feedback message identifying the latest flush location
to the server. This option is useful to make pg_receivexlog behave as sync
standby by using replication slot, for example.

Original patch by Furuya Osamu, heavily rewritten by me.
Reviewed by Heikki Linnakangas, Alvaro Herrera and Sawada Masahiko.
This commit is contained in:
Fujii Masao
2014-11-18 02:32:48 +09:00
parent bc241488b0
commit c4f99d2029
5 changed files with 54 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
doc/src/sgml/ref/pg_receivexlog.sgml
View File

@ -48,6 +48,13 @@ PostgreSQL documentation
<application>pg_receivexlog</application>.
</para>
<para>
Unlike the standby's WAL receiver, <application>pg_receivexlog</>
flushes WAL data only when WAL file is closed, by default.
<literal>--synchronous</> option must be specified to flush WAL data
in real time and ensure it's safely flushed to disk.
</para>
<para>
The transaction log is streamed over a regular
<productname>PostgreSQL</productname> connection, and uses the replication
@ -85,21 +92,6 @@ PostgreSQL documentation
</listitem>
</varlistentry>
<varlistentry>
<term><option>-F <replaceable class="parameter">interval</replaceable></option></term>
<term><option>--fsync-interval=<replaceable class="parameter">interval</replaceable></option></term>
<listitem>
<para>
Specifies the maximum time to issue sync commands to ensure the
received WAL file is safely flushed to disk, in seconds. The default
value is zero, which disables issuing fsyncs except when WAL file is
closed. If <literal>-1</literal> is specified, WAL file is flushed as
soon as possible, that is, as soon as there are WAL data which has
not been flushed yet.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option></term>
<term><option>--no-loop</option></term>
@ -135,15 +127,25 @@ PostgreSQL documentation
When this option is used, <application>pg_receivexlog</> will report
a flush position to the server, indicating when each segment has been
synchronized to disk so that the server can remove that segment if it
is not otherwise needed. When using this parameter, it is important
to make sure that <application>pg_receivexlog</> cannot become the
synchronous standby through an incautious setting of
<xref linkend="guc-synchronous-standby-names">; it does not flush
data frequently enough for this to work correctly.
is not otherwise needed. <literal>--synchronous</literal> option must
be specified when making <application>pg_receivexlog</> run as
synchronous standby by using replication slot. Otherwise WAL data
cannot be flushed frequently enough for this to work correctly.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--synchronous</option></term>
<listitem>
<para>
Issue sync commands as soon as there is WAL data which has not been
flushed yet. Also status packets are sent back to the server just after
WAL data is flushed whatever <literal>--status-interval</> is set to.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option></term>
<term><option>--verbose</option></term>