Re: Reporting the commit LSN at commit time

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 08/08/2014 03:54 AM, Tom Lane wrote:
>> FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
>> at all. What happens five years from now when we switch to some other
>> implementation that doesn't have LSNs?

> Everyone who's relying on them already via pg_stat_replication, etc, breaks.
> They're _already_ exposed to users. That ship has sailed.

They're exposed to replication tools, yeah, but embedding them in the
wire protocol would be moving the goalposts a long way past that. As an
example of something that doubtless seemed like a good idea at the time,
consider the business about how an INSERT command completion tag includes
the OID of the inserted row. We're stuck with that obsolete idea
*forever* because it's embedded in the protocol for all clients.

>> This position also obviates the need to complain about having a GUC
>> that changes the protocol-level behavior, which is also a seriously
>> bad idea.

> Well, I'd prefer to be able to negotiate with the server and establish
> requirements during the protocol handshake.

Sure, but a GUC is not that. The problem with a GUC for changing
wire-level behavior is that it might be set by code far removed from
the wire, possibly breaking lower code levels that expected different
behavior. The multitude of ways that we offer for setting GUCs is
an active evil in this particular context.

regards, tom lane