On Thu, 19 Feb 2026 at 02:50, Andres Freund <[email protected]> wrote:
>
> Hi,
>
> On 2026-02-18 09:46:43 -0600, Nathan Bossart wrote:
> > On Wed, Feb 18, 2026 at 12:13:46PM +0500, Kirill Reshke wrote:
> > > Hi! I tested patch under --single (single user mode), and ISTM that we
> > > can reach palloc from ProcessInterrups here?
> > > Maybe we should not elog in single user mode inside sighandler...
> >
> > This is reproducible even without single-user mode by sending SIGQUIT to a
> > client backend. Both die() and quickdie() call ereport(), and both are
> > commonly used as signal handlers for SIGTERM and SIGQUIT.
>
> I don't think die() should call ereport() without being in single user mode. I
> guess there's a corner case though, which is that the signal handler is
> executed during exit processing, when we already reset whereToSendOutput. I
> think we probably should make sure this stuff is only reached in actual single
> user mode.
Hi! Thank you for your input.
Stupid question from me: in singleuser mode, how should this work? We
still should not ereport inside signal handlers, are we?
If singleuser mode is somehow safe with die & ereport then... I don't
understand how.
> I'm somewhat confused by
>
> /* Don't joggle the elbow of proc_exit */
> if (!proc_exit_inprogress)
> {
> InterruptPending = true;
> ProcDiePending = true;
> }
>
> because the only thing that avoids is actually harmless stuff, we're not going
> to notice that , whereas the ProcessInterrupts() done further down is actually
> certainly "joggling the elbow of proc_exit().
>
> <digs>
>
> I think the comment hasn't quite kept up with the time, the block used to do
> more. Some dude named Andres didn't remove the comment in commit 2505ce0be0b.
>
> And another dude, confusingly also named Andres, in commit 4f85fde8eb86,
> didn't think about the scenario that whereToSendOutput could already be reset
> to DestNone in die()
>
> Ooops.
Thanks for the history overview here. I think you can actually reach
Andres and ask him in-person about those commits, I heard he is also
employed by Microsoft.
>
> quickdie() obviously does does reach the ereport(). I think it's a bad idea,
> with a bad justification: For one, libpq makes up the same error reason if the
> client just vanishes. For another, because it just uses
> WARNING[_CLIENT_ONLY], it'll not even reach clients if they use a higher
> client_min_messages.
>
> Just hoping that the client communication, including openssl, is in a state
> that makes it somewhat safe to send messages from a signal handler, is
> bonkers, IMNSHO. Yes, we have the "safety" mechanism of postmaster SIGKILLing
> processes, but that only protects against self deadlocks, not against
> corrupted datastructures etc.
>
> It's one thing to ereport() in a signal handler during a crash triggered
> quickdie(), the shit already has hit the fan after all, but doing it as part
> of an intended immediate shutdown is a seriously bad idea.
>
So, after all, we need to remove ereport from quick die completely, no
backup plan?
This will make whole system less verbose about its shutdown reasons...
Not sure how vital that is
--
Best regards,
Kirill Reshke
