Re: WAL Insertion Lock Improvements - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: WAL Insertion Lock Improvements
Date
Msg-id CALj2ACWcJvqqWmzawyw_=ycSHty06H+EAAjzSQ5Hfq8kvpaJFA@mail.gmail.com
Whole thread Raw
In response to Re: WAL Insertion Lock Improvements  (Michael Paquier <michael@paquier.xyz>)
Responses Re: WAL Insertion Lock Improvements
List pgsql-hackers
On Fri, Jul 21, 2023 at 11:29 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> +       /* Reading atomically avoids getting a torn value */
> +       value = pg_atomic_read_u64(valptr);
>
> Should this specify that this is specifically important for platforms
> where reading a uint64 could lead to a torn value read, if you apply
> this term in this context?  Sounding picky, I would make that a bit
> longer, say something like that:
> "Reading this value atomically is safe even on platforms where uint64
> cannot be read without observing a torn value."
>
> Only xlogprefetcher.c uses the term "torn" for a value by the way, but
> for a write.

Done.

> 0001 looks OK-ish seen from here.  Thoughts?

Yes, it looks safe to me too. FWIW, 0001 essentially implements what
an existing TODO comment introduced by commit 008608b9d5106 says:

    /*
     * Read value using the lwlock's wait list lock, as we can't generally
     * rely on atomic 64 bit reads/stores.  TODO: On platforms with a way to
     * do atomic 64 bit reads/writes the spinlock should be optimized away.
     */

I'm attaching v10 patch set here - 0001 has modified the comment as
above, no other changes in patch set.

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

Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition
Next
From: Amit Kapila
Date:
Subject: Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.