From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reporting the commit LSN at commit time |
Date: | 2014-08-10 08:30:21 |
Message-ID: | 20140810083021.GE1323@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <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.
> >
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-08-10 09:22:50 | Re: Minmax indexes |
Previous Message | Amit Kapila | 2014-08-10 07:38:38 | Re: postgresql.auto.conf and reload |