Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher |
Дата | |
Msg-id | CAB7nPqT0KTESND2GHggc4WhZYajs+znP_Hhik8+5A7Mehg_L0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
|
Список | pgsql-hackers |
On Tue, May 2, 2017 at 4:11 PM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > On 02/05/17 05:35, Michael Paquier wrote: >> On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut >> <peter.eisentraut@2ndquadrant.com> wrote: >>> On 4/25/17 21:47, Michael Paquier wrote: >>>> Attached is an updated patch to reflect that. >>> >>> I edited this a bit, here is a new version. >> >> Thanks, looks fine for me. >> >>> A variant approach would be to prohibit *all* new commands after >>> entering the "stopping" state, just let running commands run. That way >>> we don't have to pick which individual commands are at risk. I'm not >>> sure that we have covered everything here. >> >> It seems to me that everything is covered. We are taking about >> creation and dropping of slots here, where standby snapshots can be >> created and SQL queries can be run when doing a tablesync meaning that >> FPWs could be taken in the context of the WAL sender. Blocking all >> commands would be surely safer I agree, but I see no reason to block >> things more than necessary. >> > > I don't think the code covers all because a) the SQL queries are not > covered at all that I can see and b) logical decoding can theoretically > do HOT pruning (even if the chance is really small) so it's not safe to > start logical replication either. Ahhh. So START_REPLICATION can also now generate WAL. Good to know. -- Michael
В списке pgsql-hackers по дате отправления: