Hi On 2022-04-17 12:01:53 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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
