| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Subject: | Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate() |
| Date: | 2021-09-13 17:12:48 |
| Message-ID: | 463982.1631553168@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-09-13 18:28:55 | Re: PG Docs - CREATE SUBSCRIPTION option list order |
| Previous Message | Matthias van de Meent | 2021-09-13 17:12:42 | Re: 64 bit TID? |