Re: Can we get rid of TerminateThread() in pg_dump?

On Wed, 8 Jul 2026 at 17:49, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > Without any synchronization primitives there's still room for a
> > data-race, right?
>
> The network operations on the cancel thread (to send cancellation) and
> on the other thread (to receive the error messages from the server)
> should act as reliable memory barriers.

This is true for errors originating from the cancellation, but not for
an unluckily timed random other error. If an error occurs in a worker
query at the same time that the cancel flag is flipped, then the
worker thread could read the cancel_in_progress flag. In practice the
read would return either true or false and both values are acceptable,
so it doesn't matter. But strictly speaking, such a read pattern is a
data race that violates the C abstract machine and thus results in
undefined behaviour. But like I said in practice it doesn't matter,
especially if we swap this out for an atomic operation soon(tm).

> Ok, committed, thank you!

Awesome!

> Ack. I'm getting a little confused by all the interdependent patches
> flying around. But as long as we keep grinding, committing what we can
> one patch at a time and rebasing all remaining ones, we'll be done
> eventually :-).

Yeah, agreed. Thanks for closing this thread out at least.