On 2014-08-07 21:02:54 -0400, Tom Lane wrote: > Craig Ringer <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
