Re: [PATCH] Add recovery_min_apply_delay_reconnect recovery option

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

In response to

Browse pgsql-hackers by date

  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