[HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

This is a patch I am using in production using the following parameters
in recovery.conf:

    recovery_min_apply_delay = '1d'
    recovery_min_apply_delay_reconnect = '10 min'

In our environment we expect that standby servers with an apply delay
provide some protection against mistakes by the DBA (myself), and that
they contain a valid copy of the data that can be used in the event that
the master dies.

Does this feature seems applicable to a wider community?


== delay-reconnect-param ==

Add recovery_min_apply_delay_reconnect recovery option

'recovery_min_apply_delay_reconnect' allows an administrator to specify
how a standby using 'recovery_min_apply_delay' responds when streaming
replication is interrupted.

Combining these two parameters provides a fixed delay under normal
operation while maintaining some assurance that the standby contains an
up-to-date copy of the WAL.

This administrative compromise is necessary because the WalReceiver is
not resumed after a network interruption until all records are read,
verified, and applied from the archive on disk.

Is it possible to verify the archive on disk independently of
application?  Adding a second delay parameter provides a workaround for
some use cases without complecting xlog.c.

 doc/src/sgml/recovery-config.sgml       | 24 ++++++++++++++++++++++++
 src/backend/access/transam/xlog.c       | 59 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 src/test/recovery/t/005_replay_delay.pl |  8 ++++++--
 3 files changed, 76 insertions(+), 15 deletions(-)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers