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>

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-01-20T01:47:57Z

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-10 at 19:59 +0530, Bharath Rupireddy wrote:
> I've addressed the above review comments and attached v19 patch-set.

Regarding:

-       if (!WALRead(state, cur_page, targetPagePtr, XLOG_BLCKSZ, tli,
-                                &errinfo))
+       if (!WALRead(state, cur_page, targetPagePtr, count, tli,
&errinfo))

I'd like to understand the reason it was using XLOG_BLCKSZ before. Was
it a performance optimization? Or was it to zero the remainder of the
caller's buffer (readBuf)? Or something else?

If it was to zero the remainder of the caller's buffer, then we should
explicitly make that the caller's responsibility.

Regards,
	Jeff Davis