On Thu, Apr 29, 2021 at 11:55 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Apr 29, 2021 at 4:58 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Thu, Apr 29, 2021 at 5:41 AM Tom Lane <t...@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. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
fix_stats_test.patch
Description: Binary data