<p dir="ltr"><br /> On 15 Aug 2014 14:54, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>
wrote:<br/> ><br /> > Andres Freund <<a href="mailto:andres@2ndquadrant.com">andres@2ndquadrant.com</a>>
writes:<br/> > > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:<br /> > >> And what does that actually
do? Send back a result-set, or a new<br /> > >> protocol message?<br /> ><br /> > > What I was
thinkingof was to return "COMMIT X/X" instead of<br /> > > "COMMIT". Since that's only sent when COMMIT WITH
(report_commit_lsnON)<br /> > > was set it won't break clients/libraries that don't need it.<br /> ><br />
>Au contraire: it will break any piece of code that is expecting a COMMIT<br /> > command tag to look like
exactly"COMMIT" and not "COMMIT something".<p dir="ltr">Two comments. Firstly, we can't freeze everything forever. This
seemslike 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.<pdir="ltr">I fear putting out anywhere but in the commit message would have race conditions. Having it in
thecommit message guarantees the client never has to deal with strange states like " I know this transaction committed
butI know when" which would make clients vastly simpler.<p dir="ltr">But secondly there will *always* be race
conditionsin this. This is the same problem as our hokey synchronous commit which commits transactions but then hides
themfrom the client. All it does is move the uncertainty around.<p dir="ltr">The long term solution will be something
morelike 2PC. At the beginning of your transaction you get an identifier for the transaction and store that in a
transactionmanager. The transaction manager knows how to determine which transcribe are committed on which nodes and
howto resolve conflicts.<br />
