Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option
Дата
Msg-id CAB7nPqTPo6a4fLt8kExU+3DKcFjtaVOs-TE3Xcg5YpurZ2BG3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnectrecovery option  (Eric Radman <ericshane@eradman.com>)
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Partition-wise aggregation/grouping
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: [HACKERS] SIGSEGV in BRIN autosummarize