Re: WAL Insertion Lock Improvements

On Fri, May 19, 2023 at 12:24 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, May 18, 2023 at 11:18:25AM +0530, Bharath Rupireddy wrote:
> > I think what I have so far seems more verbose explaining what a
> > barrier does and all that. I honestly think we don't need to be that
> > verbose, thanks to README.barrier.
>
> Agreed. This file is a mine of information.
>
> > I simplified those 2 comments as the following:
> >
> > * NB: pg_atomic_exchange_u64, having full barrier semantics will ensure
> > * the variable is updated before releasing the lock.
> >
> > * NB: pg_atomic_exchange_u64, having full barrier semantics will ensure
> > * the variable is updated before waking up waiters.
> >
> > Please find the attached v7 patch.
>
> Nit. These sentences seem to be worded a bit weirdly to me. How
> about:
> "pg_atomic_exchange_u64 has full barrier semantics, ensuring that the
> variable is updated before (releasing the lock|waking up waiters)."

I get it. How about the following similar to what
ProcessProcSignalBarrier() has?

+ * Note that pg_atomic_exchange_u64 is a full barrier, so we're guaranteed
+ * that the variable is updated before waking up waiters.
+ */

+ * Note that pg_atomic_exchange_u64 is a full barrier, so we're guaranteed
+ * that the variable is updated before releasing the lock.
*/

Please find the attached v8 patch with the above change.

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