On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <tomas.vondra@2ndquadrant.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
