On Fri, Jan 2, 2015 at 3:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > In short, you can't force 2PC technology on people who aren't using it > already; while for those who are using it already, this isn't nearly > good enough as-is.
I was involved in some internal discussions related to this patch, so I have some opinions on it. The long-term, high-level goal here is to facilitate sharding. If we've got a bunch of PostgreSQL servers interlinked via postgres_fdw, it should be possible to perform transactions on the cluster in such a way that transactions are just as atomic, consistent, isolated, and durable as they would be with just one server. As far as I know, there is no way to achieve this goal through the use of an external transaction manager, because even if that external transaction manager guarantees, for every transaction, that the transaction either commits on all nodes or rolls back on all nodes, there's no way for it to guarantee that other transactions won't see some intermediate state where the commit has been completed on some nodes but not others. To get that, you need some of integration that reaches down to the way snapshots are taken. I think, though, that it might be worthwhile to first solve the simpler problem of figuring out how to ensure that a transaction commits everywhere or rolls back everywhere, even if intermediate states might still be transiently visible. I don't think this patch, as currently designed, is equal to that challenge, because XACT_EVENT_PRE_COMMIT fires before the transaction is certain to commit - PreCommit_CheckForSerializationFailure or PreCommit_Notify could still error out. We could have a hook that fires after that, but that doesn't solve the problem if a user of that hook can itself throw an error. Even if part of the API contract is that it's not allowed to do so, the actual attempt to commit the change on the remote side can fail due to - e.g. - a network interruption, and that's go to be dealt with somehow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
