Re: Use WALReadFromBuffers in more places

From: Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
Subject: Re: Use WALReadFromBuffers in more places
Date: 2025-09-20 08:33:20
Message-ID: 92F510DF-321D-4385-B1D8-71781B50777B@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi~

> Thanks for looking at this. Yes, the WAL writers can zero out flushed
> buffers before WALReadFromBuffers gets to them. However,
> WALReadFromBuffers was intentionally designed as an opportunistic
> optimization - it's a "try this first, quickly" approach before
> falling back to reading from WAL files. The no-locks design ensures it
> never gets in the way of backends generating WAL, which is critical
> for overall system performance.

Yes, it is actually an interesting thing, beyond current topic. Since
we are using buffered I/O, even though we cannot read from WAL buffer due
to the opportunistic AdvanceXLInsertBuffer by WAL writer, later WALRead may
still find the page inside OS page cache, with high probability, because the
page has just been written out. So WALRead will be fast, too.

But if we are moving forward to direct I/O some day in the future, the cost
of WALReadFromBuffers and WALRead might be obvious. Maybe the opportunistic
WAL buffer initialization could keep a small ratio of old pages inside WAL
buffer so these pages can still be hit by WALReadFromBuffers.

> I rebased and attached the v3 patch.

The v3 patch LGTM.


Regards,
Jingtang

Alibaba Cloud

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-09-20 11:59:02 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Atsushi Torikoshi 2025-09-20 03:21:39 Re: RFC: Logging plan of the running query