Andres Freund <andres@anarazel.de> writes:
>> - On decoding of aborted xacts. The idea to throw an error once we
>> detect the abort is appealing, however I think you will have problems
>> with subxacts in the current implementation. What if subxact issues
>> DDL and then aborted, but main transaction successfully committed?
>
> I don't see a fundamental issue here. I've not reviewed the current
> patchset meaningfully, however. Do you see a fundamental issue here?
Hmm, yes, this is not an issue for this patch because after reading
PREPARE record we know all aborted subxacts and won't try to decode
their changes. However, this will be raised once we decide to decode
in-progress transactions. Checking for all subxids is expensive;
moreover, WAL doesn't provide all of them until commit... it might be
easier to prevent vacuuming of aborted stuff while decoding needs it.
Matter for another patch, anyway.
>> - Currently we will call abort_prepared cb even if we failed to actually
>> prepare xact due to concurrent abort. I think it is confusing for
>> users. We should either handle this by remembering not to invoke
>> abort_prepared in these cases or at least document this behaviour,
>> leaving this problem to the receiver side.
>
> What precisely do you mean by "concurrent abort"?
With current patch, the following is possible:
* We start decoding of some prepared xact;
* Xact aborts (ABORT PREPARED) for any reason;
* Decoding processs notices this on catalog scan and calls abort()
callback;
* Later decoding process reads abort record and calls abort_prepared
callback.
--
Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company