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.

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.



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.


Greetings,

Andres Freund


Reply via email to