From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Nathan Bossart <nathan(at)postgresql(dot)org> |
Subject: | Re: core dumps in auto_prewarm, tests succeed |
Date: | 2024-01-23 19:00:01 |
Message-ID: | 6c619653-89c5-5035-a5f4-575b4ba55336@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-01-23 19:07:08 | Re: Refactoring backend fork+exec code |
Previous Message | Peter Eisentraut | 2024-01-23 18:58:30 | Re: generate syscache info automatically |