Re: Replication slot stats misgivings
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2021-03-20T04:58:06Z
Lists: pgsql-hackers
On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund <andres@anarazel.de> wrote: > > > > And then more generally about the feature: > > - If a slot was used to stream out a large amount of changes (say an > > initial data load), but then replication is interrupted before the > > transaction is committed/aborted, stream_bytes will not reflect the > > many gigabytes of data we may have sent. > > > > We can probably update the stats each time we spilled or streamed the > transaction data but it was not clear at that stage whether or how > much it will be useful. > > > - I seems weird that we went to the trouble of inventing replication > > slot stats, but then limit them to logical slots, and even there don't > > record the obvious things like the total amount of data sent. > > > > Won't spill_bytes and stream_bytes will give you the amount of data sent? > > > > > I think the best way to address the more fundamental "pgstat related" > > complaints is to change how replication slot stats are > > "addressed". Instead of using the slots name, report stats using the > > index in ReplicationSlotCtl->replication_slots. > > > > That removes the risk of running out of "replication slot stat slots": > > If we loose a drop message, the index eventually will be reused and we > > likely can detect that the stats were for a different slot by comparing > > the slot name. > > > > 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. -- With Regards, Amit Kapila.
Commits
-
Doc: Update logical decoding stats information.
- 0c6b92d9c6fb 14.0 landed
-
Fix tests for replication slots stats.
- fc69509131c3 14.0 landed
-
Update replication statistics after every stream/spill.
- 592f00f8dec6 14.0 landed
-
Fix the computation of slot stats for 'total_bytes'.
- 205f466282be 14.0 landed
-
Another try to fix the test case added by commit f5fc2f5b23.
- 51ef9173030c 14.0 landed
-
Use HTAB for replication slot statistics.
- 3fa17d37716f 14.0 landed
-
Fix test case added by commit f5fc2f5b23.
- c64dcc7fee5f 14.0 landed
-
Add information of total data processed to replication slot stats.
- f5fc2f5b23d1 14.0 landed
-
Use NameData datatype for slotname in stats.
- cca57c1d9bf7 14.0 landed