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

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>

Cc: Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, Nathan Bossart <nathandbossart@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>

Date: 2024-02-12T19:33:24Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add XLogCtl->logInsertResult
- f3ff7bf83bce 17.0 cited
Add assert to WALReadFromBuffers().
- 9ecbf54075a9 17.0 landed
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 landed
Additional write barrier in AdvanceXLInsertBuffer().
- 766571be1659 17.0 landed
Use 64-bit atomics for xlblocks array elements.
- c3a8e2a7cb16 17.0 landed
Don't trust unvalidated xl_tot_len.
- bae868caf222 17.0 cited

On Wed, 2024-01-31 at 14:30 +0530, Bharath Rupireddy wrote:
> Please see the attached v22 patch set.

Committed 0001.

For 0002 & 0003, I'd like more clarity on how they will actually be
used by an extension.

For 0004, we need to resolve why callers are using XLOG_BLCKSZ and we
can fix that independently, as discussed here:

https://www.postgresql.org/message-id/CALj2ACV=C1GZT9XQRm4iN1NV1T=hLA_hsGWNx2Y5-G+mSwdhNg@mail.gmail.com

Regards,
	Jeff Davis