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
