Re: log XLogPrefetch stats at end of recovery

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Lakshmi N <lakshmin(dot)jhs(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: log XLogPrefetch stats at end of recovery
Date: 2026-11-11 20:57:51
Message-ID: CALj2ACVPRBZ0Lp3pcG7dks2ynRRDyAuTHrLUY=DrzGwRABBWSQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Nov 5, 2026 at 11:04 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> I have addressed comments 4 and 5 in the attached v5 patch.

Thanks for updating the patch.

> To summarize, v5 adds these:
>
> 1) Reports accumulated prefetch statistics at the end of recovery,
> regardless of whether prefetching is enabled at that point, and
> includes the current recovery_prefetch setting.
>
> 2) Adds regression tests covering zero counters and statistics
> retained after disabling prefetching.

A TAP test is an overkill here. The code is already covered in the
recovery tests [1].

> 3) Renames the function to XLogPrefetchLogStatsOnRecoveryEnd() to make
> its intended use explicit.
>
> Please take a look and let me know for any other comments.

I don't think we need to report whether recovery prefetch was on
during the recovery in the log message (sorry for saying so upthread).
BTW, even if we were to report it, RecoveryPrefetchEnabled() was the
correct one to use. But I would drop it.

Please have a look at the attached v6 with the above adjustments:
moved the log message after the existing "last completed
transaction..." message, reworded the commit message, and dropped the
TAP test. I think it is RfC. Thoughts?

[1]
LOG: redo prefetch stats: prefetched 9 blocks, skipped (0 in the
buffer pool, 5 zero-initialized, 344 non-existent, 16 full page image,
661 recently prefetched)
LOG: redo prefetch stats: prefetched 1 blocks, skipped (0 in the
buffer pool, 22 zero-initialized, 1408 non-existent, 3 full page
image, 3568 recently prefetched)
LOG: redo prefetch stats: prefetched 9 blocks, skipped (0 in the
buffer pool, 5 zero-initialized, 344 non-existent, 16 full page image,
661 recently prefetched)
LOG: redo prefetch stats: prefetched 8 blocks, skipped (1 in the
buffer pool, 5 zero-initialized, 344 non-existent, 16 full page image,
661 recently prefetched)
LOG: redo prefetch stats: prefetched 9 blocks, skipped (2 in the
buffer pool, 1 zero-initialized, 0 non-existent, 24 full page image,
148 recently prefetched)

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

Attachment Content-Type Size
v6-0001-Emit-prefetch-statistics-into-the-server-log-at-e.patch application/x-patch 3.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-11-11 21:08:28 Re: test: avoid redundant standby catchup in 049_wait_for_lsn
Previous Message Xnerv Wang 2026-11-11 19:58:12 Re: [PATCH] pg_input_is_valid() reuses the first type name inside a PL/pgSQL loop