Re: Use WALReadFromBuffers in more places

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Jeff Davis <pgsql(at)j-davis(dot)com>, Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
Subject: Re: Use WALReadFromBuffers in more places
Date: 2026-09-10 03:44:41
Message-ID: CALj2ACVWt4MPsdrSShL1=8EKh+WLz6HV-uN0LdWcecD7UBP9qw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Sep 7, 2026 at 11:27 PM Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> Hi!
> I noticed this patch did a small benchmarking on v6/v7,
> primary-standby on single vm. Seems like XLByteInSeg is really needful
> here, but I didn't find any v6 perf regression in close() syscall
> spam. I can share my bench scripts if needed.
>
> reads/bytes in benches measured using pg_stat_io
>
> The patch virtually eliminates walsender file reads (407 MB -> 818 KB).
>
> ## Results: lagging subscriber
>
> With a lagging subscriber, the patch reduces file reads by 44% and
> improves TPS (probably noise).
>
> v7 is neutral for buffered io (no regression/only 1-2% noise) and
> saves a lot of IO for direct IO.

Thanks a lot for benchmarking it. The subscriber (or for that matter
any logical decoding consumer) that closely follows the publisher WAL
gets the most out of it by avoiding disk read syscalls and IO. In
other words, all the WAL is available in the WAL buffers for the
readers before the walwriter's opportunistic page initialization zeros
them out.

> Code itself looks fine to me, don't see any major issues.

Thanks for reviewing it.

> In 0001 this comment looks unnecessarily big for me:
>
> Isn't this just a very detailed way to say "close WAL segment that you
> ought to close?". I think 0002 comment
>
> + /*
> + * Close the segment when a read fully satisfied from WAL buffers is
> + * not in the open segment, so the next file read reopens the correct
> + * one. See logical_read_xlog_page() for why this is needed.
> + */
>
> Is ok.

Yes, that works for me. Having it without getting into too much of
what the code does is good for readers. So, I used the same wording
for both 0001 and 0002, without 0002 referring to
logical_read_xlog_page().

> Also here [1] & [2], you (and Andres) suggest sending WAL before it has been
> locally written out and flushed to improve synchronous replication
> ...
> So, can you share a thread with this work or start one?

Thanks. I have been thinking about this and have it on my list for
PG20, but I do not have anything concrete to share yet. I will post
patches when I have something ready.

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

Attachment Content-Type Size
v8-0001-Use-WALReadFromBuffers-for-logical-replication-wa.patch application/x-patch 4.1 KB
v8-0002-Use-WALReadFromBuffers-for-local-WAL-reads.patch application/x-patch 3.3 KB
v8-0003-Test-reading-WAL-from-buffers-across-a-segment-bo.patch application/x-patch 6.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-09-10 03:48:23 Re: EUC_* ILIKE index scan stopped matching seq scan in v19
Previous Message Sami Imseih 2026-09-10 03:43:12 Re: pgstat: Flush some statistics within running transactions, take 2