Re: Trying out <stdatomic.h>

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Greg Burd <greg(at)burd(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Trying out <stdatomic.h>
Date: 2026-09-14 18:48:24
Message-ID: 649b0015-f345-42fe-b1ec-a23beadeec6e@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10.09.26 16:10, Greg Burd wrote:
> 1. Is an opt-in, default-off second implementation worth carrying at
> all? Tom's concern was that this not become The Only Way, hence the
> default. If the answer is no, that's fine and I'll stop pushing.

Depends on what the plan in the long term is. Just having another
variant available at compile time doesn't accomplish much by itself.
Except that we'd now have even more code to maintain. What are we
asking people to do with it? Are we asking for testing? (What kind?)
What do we do when the testing is complete?

Personally, I think a possible valuable outcome would be that we don't
have to maintain our own atomics library at all anymore, and just rely
on the compiler. This would require, most likely, some intermediate
steps and some testing and so on, but it would be good to clarify what
those steps are and whether this is indeed the goal.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Tiwari 2026-09-14 18:52:58 [Bug] Possible io_uring FD leak across crash recovery
Previous Message Andrey Borodin 2026-09-14 18:44:27 Re: Recovery does not honor io_combine_limit, causing IOPS saturation