On 2014-08-10 08:50:58 +0800, Craig Ringer wrote: > 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?
Any application doing such "transparent" failover would need to have a driver that's aware of all that anyway. They need to learn about the transaction boundaries, the commit command and such. I personally think this should mean that that feature requires an explicit API call for transaction control. Greetings, Andres Freund -- Andres Freund 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