MIME-Version: 1.0
References: 
 <CA+hUKGJgO=o-vLFahGdR2WesuX3h1-0j=a8z72fChc-MG1Hveg@mail.gmail.com>
 <56821e0d-bfd5-4619-b13f-12e28c78289b@iki.fi>
 <faea6e93-32ab-46ad-8caa-4f502cb3e63c@gmail.com>
In-Reply-To: <faea6e93-32ab-46ad-8caa-4f502cb3e63c@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sat, 4 Jul 2026 12:51:08 +1200
Message-ID: 
 <CA+hUKGL0ZeiO0ND+ksAi5inRY98GEGtyM4t8CVhF1mZaAqYjVA@mail.gmail.com>
Subject: Re: Can we get rid of TerminateThread() in pg_dump?
To: Bryan Green <dbryan.green@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKGL0ZeiO0ND%2BksAi5inRY98GEGtyM4t8CVhF1mZaAqYjVA%40mail.gmail.com>
Precedence: bulk

On Sat, Jul 4, 2026 at 3:36=E2=80=AFAM Bryan Green <dbryan.green@gmail.com>=
 wrote:
> On 7/3/2026 10:05 AM, Heikki Linnakangas wrote:
> >> Apparently this hasn't been a problem in practice.  Error reporting
> >> coinciding with ^C must be unlikely?  I'd still like to find a
> >> non-evil way to suppress log output, though.  What if we atomically
> >> pointed STDERR_FILENO to /dev/null, with dup2()?  I wrote a patch to
> >> try that idea out, but I don't have Windows, so I'm sharing this as a
> >> curiosity in case anyone wants to try it and/or comment on all this.
> >> Or has a better idea.  Preferably that would work on Windows and Unix
> >> (if it also used threads).
> >
> > Huh, that's pretty hacky. I think we should adopt our usual signal
> > handling approach here: Instead of calling PQcancel() from the signal
> > handler (or consoleHandler()), just set a global flag, wake up the main
> > thread, and perform the cancellation from the main thread. In the worke=
r
> > threads, you can refrain from printing the cancellation error if the
> > flag is set.
> >
> > Dunno how complicated that is to change..

> The main thread is waiting at the select()...waking that from a
> different thread is going to be doable but awkward in the current
> implementation on Windows (pipe and sockets).

I agree that, in general, cooperative/flag based interruption is the
right architecture and standard approach, and I did think a bit about
how to make that work, but I couldn't figure out how to do it without
introducing extra waits.  You'd have to ask each thread to shut down
and wait for it to acknowledge your request, but this is supposed to
be a fast shutdown, and abnormal termination.  We're subseconds away
from _exit() nuking everything, and we really just want to tell the
*server* to cancel whatever it's doing so we don't leave a long CREATE
INDEX or whatever running.  We don't actually care about the threads
themselves, and it doesn't seem that great if we have to introduce an
IPC ping-pong of some kind with each thread.  With this approach we
don't have to, we just disconnect them from stderr slightly before the
kernel vaporises them.  Doesn't seem that bad to me?