From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 1173, ... |
Date: | 2022-02-13 19:24:13 |
Message-ID: | 20220213192413.3qndul7vxpe5rbbu@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Koshakow | 2022-02-13 19:34:34 | Re: Fix overflow in DecodeInterval |
Previous Message | Andres Freund | 2022-02-13 19:14:56 | Re: Adding CI to our tree |