Re: Reporting the commit LSN at commit time

On 15 Aug 2014 14:54, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andres Freund <andres(at)2ndquadrant(dot)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.