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: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Date: 2020-06-23 05:28:18
Message-ID: CAA4eK1Jyh4qgdnxzV4fYuk9GiXLb=Uz-6o19E2RfiN8MPmUu3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >
> > >
> > >What if the decoding has been performed by multiple backends using the
> > >same slot? In that case, it will be difficult to make the judgment
> > >for the value of logical_decoding_work_mem based on stats. It would
> > >make sense if we provide a way to set logical_decoding_work_mem for a
> > >slot but not sure if that is better than what we have now.
> > >
>
> I thought that the stats are relevant to what
> logical_decoding_work_mem value was but not with who performed logical
> decoding. So even if multiple backends perform logical decoding using
> the same slot, the user can directly use stats as long as
> logical_decoding_work_mem value doesn’t change.
>

I think if you maintain these stats at the slot level, you probably
need to use spinlock or atomic ops in order to update those as slots
can be used from multiple backends whereas currently, we don't need
that.

> > >What problems do we see in displaying these for each process? I think
> > >users might want to see the stats for the exited processes or after
> > >server restart but I think both of those are not even possible today.
> > >I think the stats are available till the corresponding WALSender
> > >process is active.
>
> I might want to see the stats for the exited processes or after server
> restart. But I'm inclined to agree with displaying the stats per
> process if the stats are displayed on a separate view (e.g.
> pg_stat_replication_slots).
>

Yeah, as told previously, this makes more sense to me.

Do you think we should try to write a POC patch using a per-process
entry approach and see what difficulties we are facing and does it
give the stats in a way we are imagining but OTOH, we can wait for
some more to see if there is clear winner approach here?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-06-23 05:31:05 Re: Update InsertPgAttributeTuple comment to match new signature
Previous Message Michael Paquier 2020-06-23 05:02:33 Re: Removal of currtid()/currtid2() and some table AM cleanup