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
signature.asc
Description: PGP signature
