Re: Replication slot stats misgivings
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2021-04-29T08:26:43Z
Lists: pgsql-hackers
On Thu, Apr 29, 2021 at 11:14 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Apr 29, 2021 at 11:55 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Apr 29, 2021 at 4:58 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > On Thu, Apr 29, 2021 at 5:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > > > > > It seems that the test case added by f5fc2f5b2 is still a bit > > > > unstable, even after c64dcc7fe: > > > > > > Hmm, I don't see the exact cause yet but there are two possibilities: > > > some transactions were really spilled, > > > > > > > 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? > > Not sure but I thought that the logical decoding started to decodes > from a relatively old point for some reason and decoded incomplete > transactions that weren’t shown in the result. > > > > > > and it showed the old stats due > > > to losing the drop (and create) slot messages. > > > > > > > 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? > > Yeah, that could happen even if any message didn't get dropped. > > > > > > For the former case, it > > > seems to better to create the slot just before the insertion and > > > setting logical_decoding_work_mem to the default (64MB). For the > > > latter case, maybe we can use a different name slot than the name used > > > in other tests? > > > > > > > How about doing both of the above suggestions? Alternatively, we can > > wait for both 'drop' and 'create' message to be delivered but that > > might be overkill. > > Agreed. Attached the patch doing both things. Having a different slot name should solve the problem. The patch looks good to me. Regards, Vignesh
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