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

From Heikki Linnakangas
Subject Re: Replace pg_atomic_flag with pg_atomic_bool
Date
Msg-id 8ee2ad95-d336-48d2-8d52-df64911ae13d@iki.fi
Whole thread
In response to Re: Replace pg_atomic_flag with pg_atomic_bool  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Replace pg_atomic_flag with pg_atomic_bool
List pgsql-hackers
On 06/07/2026 18:05, Ashutosh Bapat wrote:
> 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.

The functionality is still there with my patch, as the 
pg_atomic_exchange_bool() function. Would that work for you?

- Heikki




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: remove unnecessary volatile qualifiers
Next
From: Heikki Linnakangas
Date:
Subject: Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore