Hi, On 2022-02-13 13:27:08 +0100, Tomas Vondra wrote: > I'm not sure how could this be related to the issue fixed by b779d7d8fd. > That's merely about handling of empty xacts in the output plugin, it has > little (nothing) to do with reorderbuffer - the failures was simply > about (not) printing BEGIN/COMMIT for empty xacts.
I'd only read your commit message - which didn't go into that much detail. I just saw that the run didn't yet include that commit and that the failed command specified skip-empty-xacts 1, which your commit described as fixing... > So why would it be triggering an Assert in reorderbuffer? Also, there > was a successful run with the test_decoding changes 80901b3291 (and also > with sequence decoding infrastructure committed a couple days ago) ... It's clearly a bug only happen at a lower likelihood... > Do we have access to the machine? If yes, it'd be interesting to run the > tests before the fix, and see how often it fails. Also, printing the LSN > would be interesting, so that we can correlate it to WAL. We really should provide assert infrastructure that can do comparisons while also printing values... If C just had proper generics :(. Greetings, Andres Freund