Re: Atomic ops for unlogged LSN - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Atomic ops for unlogged LSN
Date
Msg-id CALj2ACUeO0d40sKck1zvXvm8KZm9gTdzJLxSM0LYUrY11JQeRw@mail.gmail.com
Whole thread Raw
In response to Re: Atomic ops for unlogged LSN  (John Morris <john.morris@crunchydata.com>)
List pgsql-hackers
On Fri, Jul 21, 2023 at 4:43 AM John Morris <john.morris@crunchydata.com> wrote:
>
> Based on your feedback, I’ve updated the patch with additional comments.
>
> Explain the two cases when writing to the control file, and
> a bit more emphasis on unloggedLSNs not being valid after a crash.

Given that the callers already have to deal with the unloggedLSN being
reset after a crash, meaning, they can't expect an always increasing
value from unloggedLSN, I think converting it to an atomic variable
seems a reasonable change. The other advantage we get here is the
freeing up shared memory space for spinlock ulsn_lck.

The attached v2 patch LGTM and marked the CF entry RfC -
https://commitfest.postgresql.org/43/4330/.

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



pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: table_open/table_close with different lock mode
Next
From: Bharath Rupireddy
Date:
Subject: Re: Switching XLog source from archive to streaming when primary available