On 2014-08-07 21:02:54 -0400, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.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.
I don't think we really need to embed it at that level. And it doesn't
have to be always on - only clients that ask for it need to get the
answer. Something like COMMIT WITH (report_commit_lsn ON); or similar
might do the trick?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services