On Mon, Nov 1, 2021 at 12:30 AM Andres Freund <andres@anarazel.de> wrote:
> > Here are a few thoughts on how we could go about doing this. I
> > proposed them earlier in [1],
> > 1) capture and write recovery stats into a file
> > 2) capture and emit recovery stats via a new hook
> > 3) capture and write into a new system catalog table (assuming at the
> > end of the recovery the database is in a consistent state, but I'm not
> > sure if we ever update any catalog tables in/after the
> > startup/recovery phase)
> >
> > As Robert rightly suggested at [2], option (3) isn't an easy way to do
> > that so we can park that idea aside, options (1) and (2) seem
> > reasonable.
>
> I don't think 1) is a good approach, because it just leads us down the
> path of having dozens of log files.
What I had in my mind when I said "we write to a file'' was to have a
single file (similar to backup_label file) which just keeps the
last/latest recovery stats, but not all the previous recovery stats.
> 2) isn't useful either, because
> you'd need to load an extension library first, which users won't
> have done before hitting the problem.
The database vendor can implement the hook with their customizations
and load it as an extension in their postgres offerings. The postgres
will collect the recovery stats if the hook is defined and emit them
via this hook. Actually, this will be a better approach IMO. Thoughts?
> I'm not sure that the new log messages aren't sufficient. But if they
> aren't, it seems better to keep additional data in the stats system, and
> make them visible via views, rather than adding yet another place to
> keep stats.
For this, the analytic tools/users whoever wants to know the recovery
stats, will have to make connections to the database which might eat
up the total connections. Instead, the postgres emitting the stats via
a hook will be more promising. Thoughts?
Regards,
Bharath Rupireddy.