On Sun, Mar 22, 2026 at 1:43 AM Bharath Rupireddy
<[email protected]> wrote:

Hi,

> On Sat, Mar 21, 2026 at 1:16 AM SATYANARAYANA NARLAPURAM
> <[email protected]> wrote:
> >
> > > While investigating a long recovery, I noticed that XLogPrefetch stats 
> > > were not logged at the end of recovery. This log message will be useful 
> > > to understand how effective XLogPrefetch was during recovery. Adding a 
> > > patch to address this.
> >
> > Applied this patch and validated the log message. This log message appears 
> > to be useful to me, particularly while doing fleet wide analysis.
> >
> > 2026-03-20 23:33:13.756 PDT [2265441] LOG:  XLogPrefetcher stats: 
> > prefetch=14, hit=6, skip_init=5, skip_new=28, skip_fpw=18, skip_rep=996
>
> This looks useful to understand how the prefetch helped during long 
> recoveries.
>
> > I am wondering if we can periodically log this in standby mode as well, not 
> > just before promoting?
>
> Timer-based startup progress messaging allows logging such things
> (ereport_startup_progress API). There was an attempt to enable "redo
> in progress" for standbys, but that seemed to flood the standby logs
> even at the default progress interval of 10 sec.
>
> Having said that, the prefetcher stats could be added to the existing
> ereport_startup_progress("redo in progress xxx") message that works
> for crash recoveries—however, I don't prefer doing a bunch of atomic
> reads every progress interval of 10 sec.

> Therefore, logging at the end of recovery looks good to me.

+1 from me too to only of logging at the end of recovery (so -1 to logging
every now and then). If someone is interested in current state (or progress
over time) I think he can query pg_stat_recovery_prefetch view already, even
today, right?

> I reviewed the patch. I have the following comment:
>
> + elog(LOG, "XLogPrefetcher stats: prefetch=%lu, hit=%lu,
> skip_init=%lu, skip_new=%lu, skip_fpw=%lu, skip_rep=%lu",
>
> XLogPrefetcher is an internal data structure name, how about "redo
> prefetch stats: xxxx" to be consistent with other redo log messages?

+1

-J.


Reply via email to