On Fri, Mar 26, 2021 at 2:42 PM Markus Wanner <markus.wan...@enterprisedb.com> wrote: > > On 26.03.21 04:28, Amit Kapila wrote: > > I think as you have noted that stream_abort or rollback_prepared will > > be sent (the remaining changes in-between will be skipped) as we > > decode them from WAL > > Yes, but as outlined, too late. Multiple other transactions may get > decoded until the decoder reaches the ROLLBACK PREPARED. Thus, > effectively, the output plugin currently needs to deduce that a > transaction got aborted concurrently from one out of half a dozen other > callbacks that may trigger right after that transaction, because it will > only get closed properly much later. > > > so it is not clear to me how it causes any delays > > as opposed to where we don't detect concurrent abort say because after > > that we didn't access catalog table. > > You're assuming very little traffic, where the ROLLBACK ABORT follows > the PREPARE immediately in WAL. On a busy system, chances for that to > happen are rather low. >
No, I am not assuming that. I am just trying to describe you that it is not necessary that we will be able to detect concurrent abort in each and every case. Say if any transaction operates on one relation and concurrent abort happens after first access of relation then we won't access catalog and hence won't detect abort. In such cases, you will get the abort only when it happens in WAL. So, why try to get earlier in some cases when it is not guaranteed in every case. Also, what will you do when you receive actual Rollback, may be the plugin can throw it by checking in some way that it has already aborted the transaction, if so, that sounds a bit awkward to me. The other related thing is it may not be a good idea to finish the transaction before we see its actual WAL record because after the client (say subscriber) finishes xact, it sends the updated LSN location based on which we update the slot LSNs from where it will start decoding next time after restart, so by bad timing it might try to decode the contents of same transaction but may be for concurrent_aborts the plugin might arrange such that client won't send updated LSN. > (I think the same is true for streaming and stream_abort being sent only > at the time the decoder reaches the ROLLBACK record in WAL. However, I > did not try. > Yes, both streaming and 2PC behaves in a similar way in this regard. -- With Regards, Amit Kapila.
