Re: [HACKERS] logical decoding of two-phase transactions
От | Arseny Sher |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | 87a7py4iwl.fsf@ars-thinkpad обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: