On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > The previous patch would not compile on the latest HEAD. Here's updated > patch.
Perhaps unsurprisingly, this doesn't apply any more. But we have bigger things to worry about. The recent eXtensible Transaction Manager and the slides shared at the Vienna sharding summit, now posted at https://drive.google.com/file/d/0B8hhdhUVwRHyMXpRRHRSLWFXeXc/view make me think that some careful thought is needed here about what we want and how it should work. Slide 10 proposes a method for the extensible transaction manager API to interact with FDWs. The FDW would do this: select dtm_join_transaction(xid); begin transaction; update...; commit; I think the idea here is that the commit command doesn't really commit; it just escapes the distributed transaction while leaving it marked not-committed. When the transaction subsequently commits on the local server, the XID is marked committed and the effects of the transaction become visible on all nodes. I think that this API is intended to provide not only consistent cross-node decisions about whether a particular transaction has committed, but also consistent visibility. If the API is sufficient for that and if it can be made sufficiently performant, that's a strictly stronger guarantee than what this proposal would provide. On the other hand, I see a couple of problems: 1. The extensible transaction manager API is meant to be pluggable. Depending on which XTM module you choose to load, the SQL that needs to be executed by postgres_fdw on the remote node will vary. postgres_fdw shouldn't have knowledge of all the possible XTMs out there, so it would need some way to know what SQL to send. 2. If the remote server isn't running the same XTM as the local server, or if it is running the same XTM but is not part of the same group of cooperating nodes as the local server, then we can't send a command to join the distributed transaction at all. In that case, the 2PC for FDW approach is still, maybe, useful. On the whole, I'm inclined to think that the XTM-based approach is probably more useful and more general, if we can work out the problems with it. I'm not sure that I'm right, though, nor am I sure how hard it will be. -- 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
