Re: Stabilizing the test_decoding checks, take N

Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2022-04-16 13:11:59 -0400, Tom Lane wrote:
>>> We've seen this sort of problem before [2], and attempted to fix it [3]
>>> by making these tests ignore empty transactions. But of course
>>> auto-analyze's transaction wasn't empty, so that didn't help.

>> I don't quite understand this bit - the logic test_decoding uses to
>> decide if a transaction is "empty" is just whether a tuple was
>> output. And there shouldn't be any as part of auto-analyze, because we
>> don't decode catalog changes. I suspect there's something broken in the
>> streaming logic (potentially just in test_decoding) around
>> skip_empty_xacts.

Hmm, I'll defer to somebody who knows that code better about whether
there's an actual bug. However ...

>>> I think the most expedient way to prevent this type of failure is to run
>>> the test_decoding tests with autovacuum_naptime cranked up so far as to
>>> make it a non-issue, like maybe a day.

>> I'm a bit worried about this approach - we've IIRC had past bugs that
>> came only to light because of autovacuum starting. I wonder if we rather
>> should do the opposite and reduce naptime so it'll be seen on fast
>> machines, rather than very slow ones.

It seems likely to me that trying to make a test like this one blind to
autovacuum/autoanalyze activity will make it less useful, not more so.
Why is such blindness desirable?

regards, tom lane