Re: Resetting spilled txn statistics in pg_stat_replication

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Date: 2020-09-08 06:13:34
Message-ID: CAA4eK1+E427ZUfzEK8uagMm-F9n33EUBRMC99wMhk81dBRENXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 8, 2020 at 7:53 AM Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> On Mon, 7 Sep 2020 at 15:24, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> I'm still going to work on this patch although I might be slow
> response this month.
>

This is a quite fast response. Thanks for staying on top of it.

>
> >
> > 9. While reviewing this patch, I noticed that in
> > pgstat_read_db_statsfile_timestamp(), if we fail to read ArchiverStats
> > or SLRUStats, we return 'false' from this function but OTOH, if we
> > fail to read 'D' or 'R' message, we will return 'true'. I feel the
> > handling of 'D' and 'R' message is fine because once we read
> > GlobalStats, we can return the stats_timestamp. So the other two
> > stands corrected. I understand that this is not directly related to
> > this patch but if you agree we can do this as a separate patch.
>
> It seems to make sense to me. We can set *ts and then read both
> ArchiverStats and SLRUStats so we can return a valid timestamp even if
> we fail to read.
>

I have started a separate thread for this bug-fix [1] and will
continue reviewing this patch.

[1] - https://www.postgresql.org/message-id/CAA4eK1J3oTJKyVq6v7K4d3jD%2BvtnruG9fHRib6UuWWsrwAR6Aw%40mail.gmail.com

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-09-08 07:27:35 Re: default partition and concurrent attach partition
Previous Message Amit Kapila 2020-09-08 06:10:18 Inconsistency in determining the timestamp of the db statfile.