Re: Use WALReadFromBuffers in more places

Hi,

On Thu, Oct 8, 2026 at 10:37 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> It would be more correct to me to count the
> number of hits as of the *number of pages* we are able to read while
> attempting to retrieve "count" bytes worth of WAL in a single call of
> WALReadFromBuffers().
>
> If we read for example 1GB worth of data in
> one call of WALReadFromBuffers() it would be confusing to count that
> as 1 hit, that should be (1024^3 / XLOG_BLCKSZ) hits. Let's use a
> counter that is incremented while scanning the pages through the while
> loop, then increment pg_stat_io once at the end of
> WALReadFromBuffers() if (nread > 0).

Done that way.

> In terms of 0002, 0003 and 0005, anybody who does a serious review of
> this patch set will need to run benchmarks to confirm your points. If
> you could post a script, that would be useful IMO. The difficulty of
> this patch is not its implementation, it's the testing.

Sorry for not sharing them earlier. I attached the test scripts I used
for my benchmarking. I also did a new run and shared the results [1].

> I am not convinced that 0004 offers much value if integrated, still it
> seems nice to have to stress the CI.

Agreed. I dropped this patch, since we now know the fix and it works,
and v9 has it for the records.

I also did some correctness testing. I disabled the WAL writer's
opportunistic WAL buffer page initialization and forced the WAL
buffers to 2GB in the code (patch attached for this), so that most of
the WAL is available in the WAL buffers for readers, and ran make
check-world. I don't see any issues except the one TAP test failure
that happens on HEAD as well as with the patches, since it strictly
depends on the WAL buffers size.

Please find the attached v10 patches. I reworded the comments a bit
and rewrote the commit messages.

[1]
With WAL direct IO on, HEAD vs PATCHED, file reads reduced by 99.9%,
53.4% and 64.1%, and WAL disk read IO reduced by 99.9%, 98.9% and
27.8%, for the logical walsender, local WAL reads and WAL summarizer
resp. With WAL direct IO off, file reads reduced by 99.9%, 65.5% and
65.0%.

Test setup: Amazon EC2 r7i.4xlarge instance (16 vCPU, 128 GB RAM),
pg_wal on a dedicated gp3 volume. shared_buffers=8GB,
wal_buffers=16MB, max_wal_size=64GB, synchronous_commit=on. 350 byte
logical messages using pgbench with 16 clients for 180 seconds, while
the reader reads that WAL back. Each is an average of 5 runs.

0002 logical walsender:
# build WAL direct IO TPS WAL generated MB walsender read MB
file reads buffer hits WAL-disk reads WAL-disk writes replication
lag
1 HEAD on 6393 511 1056
204243 0 13.4 MB/s 9.5 MB/s 9.3 KB
2 PATCHED on 7394 591 1.5
198 240183 0.02 MB/s 10.9 MB/s 4.6 KB
3 HEAD off 7368 589 1231
239521 0 0 MB/s 10.8 MB/s 4.6 KB
4 PATCHED off 7321 585 1.8
229 237596 0 MB/s 10.8 MB/s 4.1 KB

0003 local WAL reads:
# build WAL direct IO TPS scans/s WAL generated MB reader read
MB file reads buffer hits WAL-disk reads WAL-disk writes reader
lag
1 HEAD on 6695 313 544 1476
214098 0 10.1 MB/s 9.9 MB/s 22.1 KB
2 PATCHED on 7494 493 612 779
99759 192916 0.11 MB/s 11.1 MB/s 14.9 KB
3 HEAD off 7412 491 606 1878
292188 0 0 MB/s 11.0 MB/s 14.9 KB
4 PATCHED off 7450 493 609 787
100790 193393 0 MB/s 11.0 MB/s 14.9 KB

0004 WAL summarizer:
# build WAL direct IO TPS WAL generated MB summarizer file read
MB file reads buffer hits WAL-disk reads WAL-disk writes
1 HEAD on 7366 578 582
74887 0 10.0 MB/s 12.4 MB/s
2 PATCHED on 7394 580 210
26913 48264 7.2 MB/s 10.8 MB/s
3 HEAD off 7313 574 578
74383 0 0 MB/s 10.6 MB/s
4 PATCHED off 7300 573 204
26057 48792 0 MB/s 10.6 MB/s

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