Re: Reporting the commit LSN at commit time

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".
If you think there isn't any such, a look into libpq should disabuse you
of that notion. (Admittedly, libpq's instance is only in the protocol-V2
code paths, but I'm sure that similar code exists elsewhere client-side.)

The risk still remains, therefore, that one layer of the client-side
software stack might try to enable this feature even though another
layer is not prepared for it. Changing the command tag might actually
be *more* dangerous than a new protocol message, rather than less so,
because command tags are usually exposed at multiple layers of the stack
--- libpq for instance happily returns them up to its caller. So it
will be somewhere between difficult and impossible to be sure that one
has fixed everything that needs fixing.

And, again, I think that controlling this via something as widely
changeable as a GUC is sheer folly, potentially even reaching the point
of being a security bug. (Applications that fail to recognize when
their transactions have committed would be broken in very nasty ways.)

regards, tom lane