Re: [Proposal] pg_stat_wal_records – per-record-type WAL generation statistics

Hi,

On Fri, Mar 27, 2026 at 11:27 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
>> As a whole, I am doubtful that this information is worth counting in
>> live, eating a stats kind ID. One could also implement a background
>> worker that provides more advanced aggregate stats outside the WAL
>> insert path, with a custom stats kind. No need to have that into
>> core, especially if the code that increments the stats eats more and
>> more cycles.
>
> Your argument makes sense to me, I was a bit hesitant on
> writing a background worker because of the potential side effects of tailing
> the WAL. Let me try a different approach by implementing an ondemand
> sniffing of the WAL, which can be implemented as an extension without
> changes to core. Do you have thoughts on making it a contrib module or
> modify existing pg_walinspect to accommodate these requirements?

Hi,

Please find an attached patch that implements a page_read callback
which reads WAL directly from WAL buffers using WALReadFromBuffers.
I've included a test module as a demo to show how one can collect WAL
record statistics without hitting WAL files.

The only core change needed is a fix in ReadPageInternal.
ReadPageInternal validates the first page of a WAL segment whenever it
switches to a new segment. When reading from WAL buffers, that first
page may already be overwritten by newer WAL, so we need to skip this
validation when no segment has been previously loaded (ws_segno == 0).

I understand that this will not give exact stats like the other
approaches discussed; however, it requires fewer changes to core, and
WALReadFromBuffers was designed to work without any locks, so it
should have minimal impact.

Appreciate any feedback. Thank you!

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