Re: Replication slot stats misgivings

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2021-03-20T21:27:44Z
Lists: pgsql-hackers
Hi,

On 2021-03-20 10:28:06 +0530, Amit Kapila wrote:
> On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > This idea is worth exploring to address the complaints but what do we
> > do when we detect that the stats are from the different slot? It has
> > mixed of stats from the old and new slot. We need to probably reset it
> > after we detect that.
> >
> 
> What if the user created a slot with the same name after dropping the
> slot and it has used the same index. I think chances are less but
> still a possibility, but maybe that is okay.
> 
> > What if after some frequency (say whenever we
> > run out of indexes) we check whether the slots we are maintaining is
> > pgstat.c have some stale slot entry (entry exists but the actual slot
> > is dropped)?
> >
> 
> A similar drawback (the user created a slot with the same name after
> dropping it) exists with this as well.

pgstat_report_replslot_drop() already prevents that, no?

Greetings,

Andres Freund



Commits

  1. Doc: Update logical decoding stats information.

  2. Fix tests for replication slots stats.

  3. Update replication statistics after every stream/spill.

  4. Fix the computation of slot stats for 'total_bytes'.

  5. Another try to fix the test case added by commit f5fc2f5b23.

  6. Use HTAB for replication slot statistics.

  7. Fix test case added by commit f5fc2f5b23.

  8. Add information of total data processed to replication slot stats.

  9. Use NameData datatype for slotname in stats.