> On Sat, Mar 21, 2026 at 1:16 AM SATYANARAYANA NARLAPURAM > <satyanarlapuram@gmail.com> 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?
