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

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Bryan Green <dbryan(dot)green(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: Can we get rid of TerminateThread() in pg_dump?
Date: 2026-07-06 12:18:20
Message-ID: CAGECzQRsG_0JM-P23H-1GYqr7KB6QYS9Bx2=ZwdUM9FMS7MQ_w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 5 Jul 2026 at 07:03, Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

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