On Fri, Feb 15, 2013 at 5:19 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
