Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher |
Дата | |
Msg-id | CAB7nPqSXgd=VaxX5PBp17HvkKOoZ4NtZZf2_Y8QqykEY1WprvA@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
|
Список | pgsql-hackers |
On Fri, May 5, 2017 at 11:50 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 5/5/17 01:26, Michael Paquier wrote: >> 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. > > I have committed this without the HOT pruning change. That can be > considered separately, and I think it could use another round of > thinking about it. Agreed. Just adding an ERROR message in XLogInsert() is not going to help much as this leads also to PANIC for critical sections :( So a patch really needs to be a no-op for all WAL-related operations within the WAL sender, and that will be quite invasive I am afraid. > I will move the open item to "Older Bugs" now, because the user > experience regression, so to speak, in version 10 has been addressed. > (This could be a backpatching candidate, but I am not planning on it for > next week's releases in any case.) No issues with all that. -- Michael
В списке pgsql-hackers по дате отправления: