On Fri, Feb 15, 2013 at 5:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> + CallXactCallbacks(XACT_EVENT_PRE_COMMIT);
> +
> /*
> * The remaining actions cannot call any user-defined code, so it's safe
> * to start shutting down within-transaction services. But note that most
> * of this stuff could still throw an error, which would switch us into
> * the transaction-abort path.
> */
>
> and similarly in PrepareTransaction. We're probably also going to need
> a pre-subcommit event in CommitSubTransaction --- maybe we could get
> away without that, but I'm not convinced, and we might as well change
> both the XactCallback and SubXactCallback APIs at the same time.
>
I noticed you added a pre event for commit/prepare/subcommit. That
looks good. Is there a case to add it for abort/subabort too ? I
wonder if we would want to do some cleanup on the foreign servers
before the transaction is abort-recorded on the main server. For
example, if someone wants to implement a 2PC using transaction
callbacks and need a mechanism to rollback prepared transactions
because some foreign server refused to prepare, I'm not sure if she
can use XACT_EVENT_ABORT because that callback is called while
interrupts are disabled and so it may not be safe to communicate with
the foreign servers.
> Note that this doesn't come near a true two-phase-commit protocol;
> there will still be a window wherein we've done COMMIT on the remote
> side but the local side could fail and decide to roll back. However,
> the possible errors in that window are limited and unusual, so it's
> not clear to me that it's worth working harder than this.
>
How about supporting all three modes such as 1. the current behaviour
of immediately committing at the end of a statement, 2. a full 2PC and
3. what you are proposing. The first will be fast because you don't
need additional round-trip at commit/abort but is terrible WRT data
consistency. The second is most reliable, but will have increased
transaction commit time. The third is a nice balance and can be the
default.
I understand this might be too much work for now. But it will awesome
if we can have all machinery in place to support these configurable
modes in future.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
