Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option
Date
Msg-id CAB7nPqTPo6a4fLt8kExU+3DKcFjtaVOs-TE3Xcg5YpurZ2BG3A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnectrecovery option  (Eric Radman <ericshane@eradman.com>)
List pgsql-hackers
On Tue, Oct 17, 2017 at 10:40 PM, Eric Radman <ericshane@eradman.com> wrote:
> On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote:
> I thought I had observed cases where the WalReceiver was shut down
> without causing XLogCtl->recoveryWakeupLatch to return. If I'm wrong
> about this then there's no reason to spin every n seconds.

I would expect a patch to not move the timeout calculation within the
loop in recoveryApplyDelay() as you did.

> Which record are you suggesting should be forcibly "read again"?  The
> record identified by XLogCtl->replayEndRecPtr or
> XLogCtl->lastReplayedEndRecPtr?  I'll look more carefully at such an
> approach.

I have not looked at how to do that in details, but as the delay is
applied for commit WAL records, you would need to make the redo loop
look again at this same record once you have switched back to a
streaming state. Something to be careful about is that you should not
apply the same delay multiple times for the same record.
-- 
Michael


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

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping
Next
From: Justin Pryzby
Date:
Subject: Re: [HACKERS] SIGSEGV in BRIN autosummarize