Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
Дата
Msg-id CAB7nPqQ-miZy7R2+uMJRZ26spS14E5ioHv7HFZQN_f5w0Ef6KQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Wed, May 3, 2017 at 12:25 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 5/2/17 10:08, Michael Paquier wrote:
>> On Tue, May 2, 2017 at 9:30 PM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> On 5/2/17 03:11, Petr Jelinek wrote:
>>>> logical decoding can theoretically
>>>> do HOT pruning (even if the chance is really small) so it's not safe to
>>>> start logical replication either.
>>>
>>> This seems a bit impossible to resolve.  On the one hand, we want to
>>> allow streaming until after the shutdown checkpoint.  On the other hand,
>>> streaming itself might produce new WAL.
>>
>> It would be nice to split things into two:
>> - patch 1 adding the signal handling that wins a backpatch.
>> - patch 2 fixing the side cases with logical decoding.
>
> The side cases with logical decoding are also not new and would need
> backpatching, AIUI.

Okay, I thought that there was some new concept part of logical
replication here.

>>> Can we prevent HOT pruning during logical decoding?
>>
>> It does not sound much difficult to do, couldn't you just make it a
>> no-op with am_walsender?
>
> That's my hope.

The only code path doing HOT-pruning and generating WAL is
heap_page_prune(). Do you think that we need to worry about FPWs as
well?

Attached is an updated patch, which also forbids the run of any
replication commands when the stopping state is reached.
-- 
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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Change GetLastImportantRecPtr's definition? (wasSkipcheckpoints, archiving on idle systems.)