Thread: remove volatile qualifiers from pg_stat_statements

While looking into converting pgssEntry->mutex to an LWLock (per a
suggestion elsewhere [0]), I noticed that pg_stat_statements uses
"volatile" quite liberally.  IIUC we can remove these as of commit 0709b7e
(like commits 8f6bb85, df4077c, and 6ba4ecb did in other areas).  All of
the uses in pg_stat_statements except those added by commit 9fbc3f3 predate
that commit (0709b7e), and I assume commit 9fbc3f3 was just following the
examples in surrounding code.

Am I missing something?  Or can we remove these qualifiers now?

[0] https://postgr.es/m/20200911223254.isq7veutwxat4n2w%40alap3.anarazel.de

-- 
nathan

Hi,

On Tue, Jul 30, 2024 at 01:24:54PM -0500, Nathan Bossart wrote:
> While looking into converting pgssEntry->mutex to an LWLock (per a
> suggestion elsewhere [0]), I noticed that pg_stat_statements uses
> "volatile" quite liberally.  IIUC we can remove these as of commit 0709b7e
> (like commits 8f6bb85, df4077c, and 6ba4ecb did in other areas).  All of
> the uses in pg_stat_statements except those added by commit 9fbc3f3 predate
> that commit (0709b7e), and I assume commit 9fbc3f3 was just following the
> examples in surrounding code.
> 
> Am I missing something?  Or can we remove these qualifiers now?

I share the same understanding and I think those can be removed.

The patch LGTM.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On Wed, Jul 31, 2024 at 07:01:38AM +0000, Bertrand Drouvot wrote:
> I share the same understanding and I think those can be removed.
>
> The patch LGTM.

That sounds about right.  All the volatile references we have here
have been kept under the assumption that a memory barrier is required.
As we hold spin locks in these areas, that should not be necessary
anyway.  So LGTM as well.

A quick lookup at the rest of contrib/ is showing me that the
remaining volatile references point at uses with TRY/CATCH blocks,
where we require them.
--
Michael

On Tue, Aug 06, 2024 at 04:04:01PM +0900, Michael Paquier wrote:
> On Wed, Jul 31, 2024 at 07:01:38AM +0000, Bertrand Drouvot wrote:
>> I share the same understanding and I think those can be removed.
>> 
>> The patch LGTM.
> 
> That sounds about right.  All the volatile references we have here
> have been kept under the assumption that a memory barrier is required.
> As we hold spin locks in these areas, that should not be necessary
> anyway.  So LGTM as well.

Committed, thanks.

-- 
nathan