Re: pg_dump: use threads for parallel workers on all platforms

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Bryan Green <dbryan.green@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andrew Dunstan <andrew@dunslane.net>
Date: 2026-07-05T23:21:56Z
Lists: pgsql-hackers
On 02/07/2026 19:30, Bryan Green wrote:
> None of this is broken; it works. It's threads pretending to be
> processes because the code was written for processes, and the port kept
> the protocol rather than rethinking it. I'd like to stop.
> 
> One model everywhere should be threads on all platforms, coordinated by
> an in-process work queue-- a mutex and a couple of condition variables--
> instead of two worker models bridged by an inter-process protocol.

+1

> To be clear, the unification is on the queue, not on what Windows does
> today. Teaching the non-Windows side to talk to its own threads over a
> socket, a byte at a time, would just be the same trick on more
> platforms-- that's the part worth deleting, not copying.
> 
> I've done the Windows half, both to prove it out and because it's the
> coordination layer the non-Windows side would adopt. ...

I see why you developed this that way, and it makes a lot of sense. 
However, it has one downside: the Windows-only code cannot be tested 
without Windows. At quick glance, it looks reasonable, but I'm a little 
nervous committing more Windows-only code without being able to easily 
play with it myself.

Once you have the final patch ready to switch non-Windows systems to 
threaded model too, that gets easier.

> With the thread rework, fmtId's static return value, is now
> _Thread_local.
+1. This is the first _Thread_local in our codebase. It's in C11, so it 
should just work, but we'll see if the buildfarm shows any surprises...

With this, the getLocalPQExpBuffer hook is never set. I think we can 
just remove it, and rename defaultGetLocalPQExpBuffer() to 
getLocalPQExpBuffer() directly.

I noticed that we currently call setFmtEncoding() in multiple places in 
src/bin/pg_dump. I haven't looked at them closely, but I wonder if 
there's some kind of thread-safety hazards there even without these patches.

And what about the 'quote_all_identifiers' global variable? Is that set 
correctly in both models? I guess it's inherited through fork().

- Heikki