Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher |
Дата | |
Msg-id | 33b68692-c2e3-09a2-6555-61e7dc7ac950@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
|
Список | pgsql-hackers |
On 4/21/17 00:11, Michael Paquier wrote: > Hmm. I have been actually looking at this solution and I am having > doubts regarding its robustness. In short this would need to be > roughly a two-step process: > - In PostmasterStateMachine(), SIGUSR2 is sent to the checkpoint to > make it call ShutdownXLOG(). Prior doing that, a first signal should > be sent to all the WAL senders with > SignalSomeChildren(BACKEND_TYPE_WALSND). SIGUSR2 or SIGINT could be > used. > - At reception of this signal, all WAL senders switch to a stopping > state, refusing commands that can generate WAL. > - Checkpointer looks at the state of all WAL senders, looping with a > sleep call of a couple of ms, refusing to launch the shutdown > checkpoint as long as all WAL senders have not switched to the > stopping state. > - In reaper(), once checkpointer is confirmed as stopped, signal again > the WAL senders, and tell them to perform the last loop. Yeah that looks like a reasonable approach. I'm not sure why in your patch you process got_SIGUSR2 in WalSndErrorCleanup() instead of in the main loop. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: