Re: [Postgres-xc-developers] Patch correcting implicit 2-phase commit

[Michael P. <mic...@gm...>]

>
>> mds1=# select xmin,* from mds1;
>>  xmin  | col1 | col2
>> -------+------+------
>>  10420 |    4 |    4
>>  10422 |    6 |    6
>>  10312 |    2 |    2
>>  10415 |    3 |    3
>>  10421 |    5 |    5
>> (5 rows)
>>
>>
>> Note xmin keeps increasing because we closed the transaction on GTM at the
>> "finish:" label. This may or may not be ok.
>>
> This should be OK, no?
>
> Not necessarily.
>
I see, the transaction has been only partially committed so the xmin should
keep the value of the oldest GXID (in this case the one that has not been
completely committed).

If we let it open the transaction open on GTM, how do we know the GXID that
> has been used for Commit (different from the one that has been used for
> PREPARE as I recall)?
>
> We can test the behavior to see if it is ok to close this one out,
> otherwise, we have more work to do...
>

OK, I see, so not commit the transaction on GTM...
In accordance with the current patch, we can know if implicit 2PC is used
with CommitTransactionID I added in GlobalTransactionData for the implicit
2PC.
If this value is set, it means that the transaction has been committed on
Coordinator and that this Coordinator is using an implicit 2PC.
This value set also means that the the nodes are partially committed or
completely prepared.

Here is my proposition.

When an ABORT happens and CommitTransactionID is set, we do not commit the
transaction ID used for PREPARE but we commit CommitTransactionID (no effect
on visibility).
On the other hand, we register the transaction as still prepared on GTM when
Abort happens.
This could be done with the API used for explicit 2PC.

Then if there is a conflict, the DBA or a monitoring tool could use the
explicit 2PC to finish the commit of the transaction partially prepared.
This could make the deal.

What do you think about that?

I think we should fix the panic, then test how the system behaves if, even
> though the transaction is committed on one node, if we keep the transaction
> open. The XID will appear in all the snapshots and the row should not be
> viewable, and we can make sure that vacuum is also ok (should be).  If it
> works ok, then I think we should keep the transaction open on GTM until all
> components have committed.
>

The PANIC can be easily fixed. Without testing I would say that the system
may be OK, as the transaction ID is still kept alive in snapshot.
With that transaction is seen as alive in the cluster.

-- 
Michael Paquier
http://michaelpq.users.sourceforge.net