Amit, Ajin, hackers,

testing logical decoding for two-phase transactions, I stumbled over what I first thought is a bug. But comments seems to indicate this is intended behavior. Could you please clarify or elaborate on the design decision? Or indicate this indeed is a bug?

What puzzled me is that if a decoder is restarted in between the PREPARE and the COMMIT PREPARED, it repeats the entire transaction, despite it being already sent and potentially prepared on the receiving side.

In terms of `pg_logical_slot_get_changes` (and roughly from the prepare.sql test), this looks as follows:

                        data
----------------------------------------------------
 BEGIN
 table public.test_prepared1: INSERT: id[integer]:1
 PREPARE TRANSACTION 'test_prepared#1'
(3 rows)


This is the first delivery of the transaction. After a restart, it will get all of the changes again, though:


                        data
----------------------------------------------------
 BEGIN
 table public.test_prepared1: INSERT: id[integer]:1
 PREPARE TRANSACTION 'test_prepared#1'
 COMMIT PREPARED 'test_prepared#1'
(4 rows)


I did not expect this, as any receiver that wants to have decoded 2PC is likely supporting some kind of two-phase commits itself. And would therefore prepare the transaction upon its first reception. Potentially receiving it a second time would require complicated filtering on every prepared transaction.

Furthermore, this clearly and unnecessarily holds back the restart LSN. Meaning even just a single prepared transaction can block advancing the restart LSN. In most cases, these are short lived. But on the other hand, there may be an arbitrary amount of other transactions in between a PREPARE and the corresponding COMMIT PREPARED in the WAL. Not being able to advance over a prepared transaction seems like a bad thing in such a case.

I fail to see where this repetition would ever be useful. Is there any reason for the current implementation that I'm missing or can this be corrected? Thanks for elaborating.

Regards

Markus


Reply via email to