Re: Improve WALRead() to suck data directly from WAL buffers when possible

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Date: 2023-11-04 21:27:39
Message-ID: 81ce3e64469db60b2b79173aca8a54b6cc2680b8.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2023-11-04 22:30:00 Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
Previous Message Laurenz Albe 2023-11-04 21:12:42 Re: Version 14/15 documentation Section "Alter Default Privileges"