Re: Use WALReadFromBuffers in more places

Hi,

On Tue, Oct 27, 2026 at 4:40 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> I found your performance looks very nice.

Thanks for taking a look at it.

> IIUC, the performance can be decreased
> if the wal_buffer is not enough large and walsenders always miss the cache, right?
> Can we confirm when it can happen?

It depends on a couple of things. When there are not enough WAL
buffers. When the consumers are lagging beyond the WAL being generated
i.e. insertion point. When the WAL writer's opportunistic page
initialization kicks in to zero-out the most WAL pages from the
buffers.

> Regarding the code, state->seg.ws_tli cannot be updated if logical_read_xlog_page()
> bypasses the actual WAL read. It seems to break the callback rule determined
> in xlogheader.h:
>
> ```
> * The callback shall set ->seg.ws_tli to the TLI of the file the page was
> * read from.
> */
> XLogPageReadCB page_read;
> ```

Yes, you are right. When the WAL is fully read from the buffers,
ws_tli stays 0. For the existing physical walsender the first read
always happens from a WAL file, as we attempt to read from the buffers
with ws_tli 0. I can't think of any correctness issue, but it affects
error reporting for file removal and validation checks. When reading
from the buffers, the validation checks rarely fail, because the WAL
pages are initialized atomically for next use.

I would like to fix this by setting seg.ws_tli when we skip reading
from the file.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com