| 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 |
| 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 |