Re: Use WALReadFromBuffers in more places

On Mon, Aug 17, 2026 at 04:30:00PM -0700, Bharath Rupireddy wrote:
> Test setup: two Amazon EC2 r7i.4xlarge instances (16 vCPU, 128 GB RAM)
> in the same AZ, one publisher and one subscriber, pg_wal on a
> dedicated gp3 disk. Publisher runs an insert-only pgbench workload (16
> clients) into a two-column table (bigint, text), each insert writing
> 400 bytes, no indexes. Subscriber tails closely (lag in KB) so the WAL
> the walsender reads is still in the 2 GB wal_buffers. wal_buffers=2GB,
> debug_io_direct='wal'.
>
> Metrics: TPS is publisher pgbench insert throughput. Walsender read MB
> is read_bytes from pg_stat_io for the walsender (bytes read through
> WALRead()). WAL-disk reads and WAL-disk writes are peak throughput
> from iostat on the pg_wal disk. Replication lag is
> pg_stat_replication, sampled every 5 seconds, taken as the max over
> the run.

Worth noting something in the patch: read_local_xlog_page_guts() is
touched, being called in read_local_xlog_page().
read_local_xlog_page() is used in much more contexts than just the
logical paths and pg_walinspect you are referring to at the top of
this thread. Repack workers, 2PC code, WAL summarizer have also
references to it in their XL_ROUTINE().

This uses pgbench for the WAL inserts. For the logical path, at
least, could a workload based on logical WAL messages generated by
pg_logical_emit_message() be a fancier (aka less noisy) workload to
use to compare the modes of debug_io_direct for the scope of this
patch?

I have to admit that I would be a bit stressed with changing the three
code paths for logical_read_xlog_page(), XLogSendPhysical() and
read_local_xlog_page_guts() all at once.. Checking things separately
seems like a more safer approach, because less risky in terms of
potential reverts of one part of the other if the buildfarm detects
that something is wrong, particularly on slower machines where race
condition patterns show up more easily. My 2c.
--
Michael