On 15 Aug 2014 14:54, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-08-14 12:21:38 -0400, Robert Haas wrote: > >> And what does that actually do? Send back a result-set, or a new > >> protocol message? > > > What I was thinking of was to return "COMMIT X/X" instead of > > "COMMIT". Since that's only sent when COMMIT WITH (report_commit_lsn ON) > > was set it won't break clients/libraries that don't need it. > > Au contraire: it will break any piece of code that is expecting a COMMIT > command tag to look like exactly "COMMIT" and not "COMMIT something".
Two comments. Firstly, we can't freeze everything forever. This seems like it would be the least of people's issues to deal with for an upgrade. We should search for the cleanest solution, not bolt on features for fear that integrating them where they make the most sense might break someone's code somewhere. I fear putting out anywhere but in the commit message would have race conditions. Having it in the commit message guarantees the client never has to deal with strange states like " I know this transaction committed but I know when" which would make clients vastly simpler. But secondly there will *always* be race conditions in this. This is the same problem as our hokey synchronous commit which commits transactions but then hides them from the client. All it does is move the uncertainty around. The long term solution will be something more like 2PC. At the beginning of your transaction you get an identifier for the transaction and store that in a transaction manager. The transaction manager knows how to determine which transcribe are committed on which nodes and how to resolve conflicts.
