Re: add checkpoint stats of snapshot and mapping files of pg_logical dir

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: add checkpoint stats of snapshot and mapping files of pg_logical dir
Date: 2022-03-14 10:24:19
Message-ID: CALj2ACXC5fgo7g_jediB74g9oTJm3n2=7MW2X1Mhw5TqRi3Y8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 14, 2022 at 1:33 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Mar 14, 2022 at 10:54:56AM +0530, Bharath Rupireddy wrote:
> > Yes, this is a concern. Also, when there were no logical replication
> > slots on a plain server or the server removed or cleaned up all the
> > snapshot/mappings files, why would anyone want to have these messages
> > with all 0s in the server log?
>
> The default settings don't enable that, so making things conditional
> roughly as you are suggesting with two different LOG messages sounds
> rather fine.
>
> > Here's what I'm thinking:
> >
> > Leave the existing "checkpoint/restartpoint complete" messages intact,
> > add the following in LogCheckpointEnd:
>
> FWIW, I also think that it would be good to check if there are cases
> where this information is significant enough that its inclusion makes
> sense. In the top message of the thread, the logs you showed refer to
> operations that represent 1/2ms worth of checkpoint. So, if in most
> cases this is going to be very quick, adding it to the logs won't
> matter because that's not a performance bottleneck.

At times, the snapshot or mapping files can be large in number and one
some platforms it takes time for checkpoint to process all of them.
Having the stats about them in server logs can help us better analyze
why checkpoint took a long time and provide a better RCA.

> Perhaps that's
> something the patch that works on progress reporting for checkpoint
> is able to track?

pg_stat_progress_checkpoint will give the info about the on-going
checkpoint but the info in the server logs will help analyze the
issues after they occur.

Regards,
Bharath Rupireddy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2022-03-14 10:26:16 Re: Implementing Incremental View Maintenance
Previous Message Yugo NAGATA 2022-03-14 10:12:17 Re: Implementing Incremental View Maintenance