| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: convert various variables to atomics |
| Date: | 2026-09-08 17:13:57 |
| Message-ID: | aqBCVaif0HXXM7OO@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 06, 2026 at 11:37:46AM +0300, Heikki Linnakangas wrote:
> On 04/08/2026 17:32, Andres Freund wrote:
>> I'm quite hesitant to do that, at least without a lot more clear cut examples
>> where it actually would make the code better. I think it's rarely a good idea
>> to use signed variables for atomics, because you get undefined behaviour on
>> overflow, there's problems with bit masking, etc. IME most data in atomically
>> modified should actually be unsigned and probably should have been unsigned
>> before the conversion to atomics.
>
> We could provide pg_atomic_read/write_i32() and
> pg_atomic_compare_exchange_i32() but leave out fetch-and-add and other such
> instructions that have overflow or bit masking issues.
I would do both of these, i.e., first try switching to unsigned, and if
that's not an option for whatever reason, use signed atomics. If those
existed, I'd use them for v2-0002, which uses an atomic variable for an
enum value, and v2-0005, which uses an atomic variable for a Buffer.
Neither needs to do any sort of atomic arithmetic on the value, so the lack
of fetch-and-add, etc., isn't a problem.
That being said, adding signed atomics just for these small patches seems
rather extreme, so unless we see ourselves using them quite a bit more down
the road, my feeling is that the juice isn't worth the squeeze. I'm
curious how others feel about this.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-09-08 17:23:52 | Re: REPACK (CONCURRENTLY) doesn't check the table AM |
| Previous Message | Bharath Rupireddy | 2026-09-08 17:11:23 | Re: Teach pg_upgrade to deal with invalid databases |