| 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.
| 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 |