Re: Reporting the commit LSN at commit time

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reporting the commit LSN at commit time
Date: 2014-08-07 10:47:08
Message-ID: CA+CSw_tLwGQ5yJvRFwV4+hYXgjCpRCvGaZHGhrrR4tdp3rGOpw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 7, 2014 at 4:15 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> I'm thinking about adding a new message type in the protocol that gets
> sent immediately before CommandComplete, containing the LSN of the
> commit. Clients would need to enable the sending of this message with a
> GUC that they set when they connect, so it doesn't confuse clients that
> aren't expecting it or aware of it.
>
> Is this something you can see being useful for other non-BDR purposes?

I have been thinking about something similar.

For regular streaming replication you could keep track of the commit
LSN on a per client basis and automatically redirect read queries to a
standby if standby apply location is larger than the commit LSN of
this particular client. This can be done mostly transparently for the
application while not running into the issue that recent modifications
disappear for a while after commit.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-08-07 10:54:01 Re: posix_fadvise() and pg_receivexlog
Previous Message Maxence Ahlouche 2014-08-07 10:42:23 [GSoC] kmedoids status report