Re: core dumps in auto_prewarm, tests succeed
От | Alexander Lakhin |
---|---|
Тема | Re: core dumps in auto_prewarm, tests succeed |
Дата | |
Msg-id | 6c619653-89c5-5035-a5f4-575b4ba55336@gmail.com обсуждение исходный текст |
Ответ на | Re: core dumps in auto_prewarm, tests succeed (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: core dumps in auto_prewarm, tests succeed
|
Список | pgsql-hackers |
23.01.2024 20:30, Andres Freund wrote: > I don't think that's viable and would cause more problems than it solves, it'd > make us think that we might have an old postgres process hanging around that > needs to be terminted before we can start up. And I simply don't see the point > - we already record whether we crashed in the control file, no? With an Assert injected in walsender.c (as in [1]) and test 012_subtransactions.pl modified to finish just after the first "$node_primary->stop;", I see: pg_controldata -D src/test/recovery/tmp_check/t_012_subtransactions_primary_data/pgdata/ Database cluster state: shut down But the assertion undoubtedly failed: grep TRAP src/test/recovery/tmp_check/log/* src/test/recovery/tmp_check/log/012_subtransactions_primary.log:TRAP: failed Assert("0"), File: "walsender.c", Line: 2688, PID: 142201 As to the need to terminate a process, which is supposedly hanging around, I think, this situation doesn't differ in general from what we have after kill -9... So my point was to let 'pg_ctl stop' know about an error occurred during the server stop. [1] https://www.postgresql.org/message-id/290b9ae3-98a2-0896-a957-18d3b60b6260%40gmail.com Best regards, Alexander
В списке pgsql-hackers по дате отправления: