Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()

On Mon, Sep 13, 2021 at 10:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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?
>

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.