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? > 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? > 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. -- With Regards, Amit Kapila.
