Re: Stabilizing the test_decoding checks, take N

Hi

On 2022-04-17 12:01:53 -0400, Tom Lane wrote:
> 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?

Maybe I misunderstood - I thought you were proposing to prevent
autovacuum by increasing naptime? Won't that precisely blind us to
autovacuum/analyze? Hiding empty xacts happens "very late", so all the
decoding etc still happens.

Greetings,

Andres Freund