Re: Reporting the commit LSN at commit time - Mailing list pgsql-hackers

On Sat, Aug 9, 2014 at 12:54 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> 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?

And what does that actually do?  Send back a result-set, or a new
protocol message?

I don't have a very clear idea whether this is a good idea in any form
because I can't quite imagine how this is going to be used by the
client without adding an unwarranted amount of complexity there.
However, based on my experiences at EnterpriseDB, I would be extremely
wary of extending the wire protocol.  As soon as we do that, it
requires updates to a really phenomenal amount of other software.
Software using libpq may be more or less able to ignore the
difference, as long as they have a new-enough version of libpq (which
is a significant proviso).  But any driver that has its own
implementation of the wire protocol (and I think there is at least one
and maybe several important ones that do) needs updating, and anything
that acts as middleware (pgpool, pgbouncer) does too.  And it's not
just a matter of the maintainers making the appropriate changes
(though that does need to happen); it's also about everyone who is
using the new server version getting new versions of that other
software also.

So, even accepting for the moment the premise that the basic idea here
is good, I think the benefits would have to be monumental to convince
me that a protocol change is a good idea.  If we do anything like
that, we'll be hearing about the downstream damage for years.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company