On 08/10/2014 12:54 AM, Andres Freund wrote: > On 2014-08-07 21:02:54 -0400, Tom Lane wrote: >> Craig Ringer <cr...@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?
Wouldn't that force client drivers - libpq, psqlODBC, PgJDBC, etc - to all watch for explicit "COMMIT"s sent by the application and rewrite them? Applications could also then request the commit option via a driver that couldn't cope with it - which I think was one of Tom's concerns re using a GUC, too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
