Re: Replication slot stats misgivings
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, vignesh C <vignesh21@gmail.com>, Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2021-04-29T04:25:30Z
Lists: pgsql-hackers
On Thu, Apr 29, 2021 at 8:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > > This is the first test and inserts just one small record, so how it > > can lead to spill of data. Do you mean to say that may be some > > background process has written some transaction which leads to a spill > > of data? > > autovacuum, say? > > > Yeah, something like this could happen. Another possibility here could > > be that before the stats collector has processed drop and create > > messages, we have enquired about the stats which lead to it giving us > > the old stats. Note, that we don't wait for 'drop' or 'create' message > > to be delivered. So, there is a possibility of the same. What do you > > think? > > You should take a close look at the stats test in the main regression > tests. We had to jump through *high* hoops to get that to be stable, > and yet it still fails semi-regularly. This looks like pretty much the > same thing, and so I'm pessimistically inclined to guess that it will > never be entirely stable. > True, it is possible that we can't make it entirely stable but I would like to try some more before giving up on this. Otherwise, I guess the other possibility is to remove some of the latest tests added or probably change them to be more forgiving. For example, we can change the currently failing test to not check 'spill*' count and rely on just 'total*' count which will work even in scenarios we discussed for this failure but it will reduce the efficiency/completeness of the test case. > (At least not before the fabled stats collector rewrite, which may well > introduce some entirely new set of failure modes.) > > Do we really need this test in this form? Perhaps it could be converted > to a TAP test that's a bit more forgiving. > We have a TAP test for slot stats but there we are checking some scenarios across the restart. We can surely move these tests also there but it is not apparent to me how it can create a difference? -- 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