On Mon, Sep 13, 2021 at 10:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@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? >
It is required for the cases where we are starting internal sub-transaction (when decoding via SQL SRF). The first AbortCurrentTransaction will make the current subtransaction state to TBLOCK_SUBABORT and then RollbackAndReleaseCurrentSubTransaction will pop and release the current subtransaction. Note that the same sequence is performed outside catch and if we comment out RollbackAndReleaseCurrentSubTransaction, there are a lot of failures in test_decoding. I have manually debugged and checked that if we don't call RollbackAndReleaseCurrentSubTransaction in the catch block, it will retain the transaction in a bad state which on the next operation leads to a FATAL error. > * 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? > There are two different ways which deal with the re-thrown error. For WALSender processes, we don't start internal subtransaction and on error, they simply exist. For SQL SRFs, we start internal transactions which will be released in the catch block, and then the top transaction will be aborted after we re-throw the error. The cases where we don't immediately rethrow are specifically for streaming transactions where we might have already sent some changes to the subscriber and we want to continue processing and send the abort to subscribers. -- With Regards, Amit Kapila.
