Re: Can we get rid of TerminateThread() in pg_dump? - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Can we get rid of TerminateThread() in pg_dump?
Date
Msg-id CAGECzQRsG_0JM-P23H-1GYqr7KB6QYS9Bx2=ZwdUM9FMS7MQ_w@mail.gmail.com
Whole thread
In response to Re: Can we get rid of TerminateThread() in pg_dump?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Can we get rid of TerminateThread() in pg_dump?
List pgsql-hackers
On Sun, 5 Jul 2026 at 07:03, Thomas Munro <thomas.munro@gmail.com> wrote:
> I didn't even look into that, because I was deliberately trying to
> avoid needing atomics from here, because I need this to work on Unix
> too, and I didn't want to open too many cans of worms at the same
> time.

We do have cross-platform locks on the frontend, so we could use those
for now if needed. I don't think this needs atomic for performance
reasons and once we have atomics on the frontend it should be easy to
swap out the a lock for an atomic operation.

> 1. If we're ready to drop VS < 2022 and GCC < 4.9, we could just use
> <stdatomic.h> directly in frontend code (independently of the project
> to use it in the backend).

I think we are ready, see this thread[1].

We'd still need a MacOS version of stdatomic.h though before we could
rely on it.

[1]: https://www.postgresql.org/message-id/2a965ac6-fa42-4054-bee0-b1618e7729d6@eisentraut.org



pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: File locks for data directory lockfile in the context of Linux namespaces
Next
From: Matthias van de Meent
Date:
Subject: Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions