Re: Improve WALRead() to suck data directly from WAL buffers when possible
От | Jeff Davis |
---|---|
Тема | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
Дата | |
Msg-id | 81ce3e64469db60b2b79173aca8a54b6cc2680b8.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Improve WALRead() to suck data directly from WAL buffers when possible (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Improve WALRead() to suck data directly from WAL buffers when possible
|
Список | 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 по дате отправления: