Re: Improve WALRead() to suck data directly from WAL buffers when possible - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Improve WALRead() to suck data directly from WAL buffers when possible
Date
Msg-id 81ce3e64469db60b2b79173aca8a54b6cc2680b8.camel@j-davis.com
Whole thread Raw
In response to Re: Improve WALRead() to suck data directly from WAL buffers when possible  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Improve WALRead() to suck data directly from WAL buffers when possible
List pgsql-hackers
On Sat, 2023-11-04 at 20:55 +0530, Bharath Rupireddy wrote:
> +        XLogRecPtr    EndPtr =
> pg_atomic_read_u64(&XLogCtl->xlblocks[curridx]);
> +
> +        /*
> +         * xlblocks value can be InvalidXLogRecPtr before
> the new WAL buffer
> +         * page gets initialized in AdvanceXLInsertBuffer.
> In such a case
> +         * re-read the xlblocks value under the lock to
> ensure the correct
> +         * value is read.
> +         */
> +        if (unlikely(XLogRecPtrIsInvalid(EndPtr)))
> +        {
> +            LWLockAcquire(WALBufMappingLock,
> LW_EXCLUSIVE);
> +            EndPtr = pg_atomic_read_u64(&XLogCtl-
> >xlblocks[curridx]);
> +            LWLockRelease(WALBufMappingLock);
> +        }
> +
> +        Assert(!XLogRecPtrIsInvalid(EndPtr));

Can that really happen? If the EndPtr is invalid, that means the page
is in the process of being cleared, so the contents of the page are
undefined at that time, right?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Version 14/15 documentation Section "Alter Default Privileges"
Next
From: Bharath Rupireddy
Date:
Subject: Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)