Re: Replace pg_atomic_flag with pg_atomic_bool - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Replace pg_atomic_flag with pg_atomic_bool
Date
Msg-id CAExHW5uZmQ9DTXz79LcaaVEJyVYfKLSDMRS+51AyRz_CKkUtrA@mail.gmail.com
Whole thread
In response to Replace pg_atomic_flag with pg_atomic_bool  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Replace pg_atomic_flag with pg_atomic_bool
List pgsql-hackers
On Mon, Jul 6, 2026 at 3:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

>
> I think that's because I think of pg_atomic_flag as an atomic version of
> "bool". I'd assume there to be functions similar to the u32/u64
> functions, like pg_atomic_read_bool() and pg_atomic_write_bool(). But
> alas, neither of those functions exist. To read the value, you have to
> use pg_atomic_unlocked_test_flag(), and remember that when the flag is
> set, it returns *false*, which feels completely backwards to me. It
> makes more sense with pg_atomic_test_set_flag(), which returns 'false'
> if the flag was already set and hence was not set again, but it
> nevertheless just feels wrong to me.
>

I am using pg_atomic_test_set_flag() as a non-wait locking, lighter
than LWLock mechanism in shared buffer resizing patches. That might
change in future. But I think there's use for TAS kind of semantics.
But I have also got confused when looking at it as pg_atomic_bool. I
think we need both.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Re-read subscription state after lock in AlterSubscription
Next
From: Matthias van de Meent
Date:
Subject: Re: VACUUM FULL or CREATE INDEX fails with error: missing chunk number 0 for toast value XXX