> I must be missing something in this discussion, cos I don't see any
> problems with this "other option".
>
> Surely we prepare the 2PCxact and then it is persistent. Yes,
> potentially for an unbounded period of time. And it is (usually) up to
> the XA manager to resolve that. 2PC interacts with transaction
> management and yes, it can be slow. But the choice is slow and
> consistent, or not. This would only be used with the full choice of
> the user, just like synchronous_commit.
>
> In this case, we call the decoding plugin's precommit hook which would
> then prepare the 2PCxact and set a non-persistent flag saying it is
> being decoded. If decoding completes normally we release the lock and
> commit. If decoding fails or the DBA has another reason to do so, we
> provide a function that allows the flag to be unlocked. While it is
> locked the 2PCxact cannot be aborted or committed.
>
> There is no danger of accidental abort because the prepare has persistent state.
This concurrent abort handling while decoding is ongoing is turning
out to be complex affair.
Thinking more about this, just to provide an example, we have a
decoding plugin hook to determine if a GID for a 2PC was decoded at
PREPARE time or COMMIT time as part of the 2PC logical decoding patch.
We need that to determine the *same* static answer every time we see a
specific GID while decoding across restarts; the plugin should know
what it had done the last time around and should tell us the same
later as well. It just occurred to me that as Simon also mentioned, it
could/should also be the decoding plugin's responsibility to indicate
if it's ok to go ahead with the abort of the transaction.
So, we could consider adding a preAbort hook. That preAbort hook gets
the GID, XID and other parameters as needed and tells us whether we
can go ahead with the abort or if we need to wait out (maybe we pass
in an ok_to_wait param as well). As an example, a plugin could lookup
some shmem structure which points to the current transaction being
decoded and does related processing to ensure that it stops decoding
at a clean juncture, thus keeping the response time bounded to a
maximum of one change record apply cycle. That passes the onus onto
the plugin writers and keeps the core code around this concurrent
abort handling clean.
I will cook up something along the above lines unless there are any
objections to this approach.
Regards,
Nikhils
--
Nikhil Sontakke http://www.2ndQuadrant.com/
PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services