From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Nico Williams <nico(at)cryptonector(dot)com>, Asim R P <apraveen(at)pivotal(dot)io>, Jimmy Yih <jyih(at)pivotal(dot)io>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket |
Date: | 2018-08-08 16:19:34 |
Message-ID: | 8f920270-c3e2-17e9-dd53-150af2a84d13@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/07/18 18:03, Andres Freund wrote:
> On 2018-07-20 11:53:32 +0300, Heikki Linnakangas wrote:
>> But I think we have consensus on replacing the exit(2) calls
>> with _exit(2). If we do just that, it would be better than the status quo,
>> even if it doesn't completely fix the problem. This would prevent the case
>> that Asim reported, for starters.
>
> Right. You're planning to backpatch?
Yeah. Committed and back-patched.
>> With _exit(), I think we wouldn't really need the "PG_SETMASK(&BlockSig);"
>> calls in the aux process *_quickdie handlers that don't do anything else
>> than call _exit(). But I didn't dare to remove them yet.
>
> I think we should remove it at least in master.
Removed.
> It's much less the exit() that's unsafe, than the callbacks themselves,
> right? Perhaps just restate that we wouldn't want to trigger atexit
> processing due to signal safety?
Well, in principle exit() is unsafe too, although you're right that in
practice it's more likely the callbacks that would cause trouble. I
reworded the comment to put more emphasis on the callbacks.
On 23/07/18 17:34, Robert Haas wrote:
> +1 for trying to improve this by using _exit rather than exit, and for
> not letting the perfect be the enemy of the good.
>
> But -1 for copying the language "if some idiot DBA sends a manual
> SIGQUIT to a random backend". I think that phrase could be deleted
> from this comment -- and all of the other places where this comment
> appears already today -- without losing any useful informational
> content. Or it could be rephrased to "if this process receives a
> SIGQUIT". It's just not necessary to call somebody an idiot to
> communicate the point.
Rephrased to be less offensive.
So, with this commit, the various SIGQUIT quickdie handlers are in a
better shape. The regular backend's quickdie() handler still calls
ereport(), which is not safe, but it's a step in the right direction.
And we haven't addressed the original complaint, which was actually
about startup_die(), not quickdie().
What should we do about startup_die()? Ideas?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-08-08 16:32:42 | Re: Scariest patch tournament, PostgreSQL 11 edition |
Previous Message | Stephen Frost | 2018-08-08 16:15:51 | Re: Standby trying "restore_command" before local WAL |