Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Date
Msg-id 463982.1631553168@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Am I the only that that thinks this code is doing far too much in a
> PG_CATCH block?

You mean the one in ReorderBufferProcessTXN?  Yeah, that is mighty
ugly.  It might be all right given that it almost immediately does
AbortCurrentTransaction, since that should basically clean up
whatever is wrong.  But I'm still full of questions after a brief
look at it.

* What is the sense in calling RollbackAndReleaseCurrentSubTransaction
after having done AbortCurrentTransaction?

* Is it really sane that we re-throw the error in some cases and
not others?  What is likely to catch that thrown error, and is it
going to be prepared for us having already aborted the transaction?
(It doesn't give me a warm feeling that the code coverage report
shows that path to be un-exercised.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: 64 bit TID?
Next
From: Tom Lane
Date:
Subject: Re: PG Docs - CREATE SUBSCRIPTION option list order