Re: pg_prewarm bgworker could break fast shutdown
От | Tom Lane |
---|---|
Тема | Re: pg_prewarm bgworker could break fast shutdown |
Дата | |
Msg-id | 1458043.1603930809@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_prewarm bgworker could break fast shutdown (Alexander Kukushkin <cyberdemn@gmail.com>) |
Список | pgsql-hackers |
Alexander Kukushkin <cyberdemn@gmail.com> writes: > I the fast shutdown was initiated before pg_prewarm managed to load > buffers from the dump (and start the main loop), the pg_prewarm > bgworker process never exits on SIGTERM and effectively preventing the > clean shutdown of the cluster. I might be wrong about this, but I suspect what you've got here is that the postmaster never launched the child bgworker (and now never will launch it), so GetBackgroundWorkerPid returns BGWH_NOT_YET_STARTED and then WaitForBackgroundWorkerShutdown keeps on waiting. If that interpretation is accurate then the same problem could occur with parallel query. (And I believe it's been sufficiently demonstrated that parallel query falls over very easily in such corner cases, so this isn't an astonishing conclusion.) I'm inclined to think what we need to do about this is to have the postmaster transition all pending worker-start requests into STOPPED state, or some new FAILED state, when it starts trying to shut stuff down. I sure don't see any such logic there now --- it just sends out a bunch of SIGTERMs and that's it. Also, it looks like bgworker_should_start_now() doesn't distinguish postmaster states that don't allow starting a bgworker right this moment, but probably will allow it later, from states in which it never will be allowed and we need to fail the request not just postpone it indefinitely. regards, tom lane
В списке pgsql-hackers по дате отправления: