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
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 |