From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Eric Radman <ericshane(at)eradman(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: [PATCH] Add recovery_min_apply_delay_reconnect recovery option |
Date: | 2017-10-17 13:47:53 |
Message-ID: | CAB7nPqTPo6a4fLt8kExU+3DKcFjtaVOs-TE3Xcg5YpurZ2BG3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 17, 2017 at 10:40 PM, Eric Radman <ericshane(at)eradman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2017-10-17 14:07:40 | Re: SIGSEGV in BRIN autosummarize |
Previous Message | Dilip Kumar | 2017-10-17 13:43:36 | Re: Partition-wise aggregation/grouping |