Hi, On Tue, Oct 27, 2026 at 4:40 AM Hayato Kuroda (Fujitsu) <[email protected]> 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
