On Fri, Aug 8, 2014 at 9:50 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 08/08/2014 03:54 AM, Tom Lane wrote:
>> Craig Ringer <craig@2ndquadrant.com> writes:
>>> Hi all
>>> To support transparent client-side failover in BDR, it's necessary to
>>> know what the LSN of a node was at the time a transaction committed and
>>> keep track of that in the client/proxy.
>>
>>> 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.
>>
>> 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.
>
> That's not to say I'm stuck to LSNs as the way to do this, just that I
> don't think that particular argument is relevant.
>
>> I don't mind if you expose some other way to inquire about LSNs, but
>> let's *not* embed it into the wire protocol. Not even as an option.
>
> Well, the underlying need here is to have the client able to keep track
> of what point in the server's time-line it must see on a replica before
> it proceeds to use that replica.
>
> So if the client does some work on server A, then for some reason needs
> to / must use server B, it can ask server B "are you replayed up to the
> last transaction I performed on server A yet?" and wait until it is.
ISTM that the proper solution to that problem is the introduction of
new synchronous replication mode which makes the transaction wait for
its WAL to be replayed by the standby. If this mode is used, a client
doesn't need to track the LSN of each transaction and check whether
the committed transaction has already replayed by the standby or not.
Regards,
--
Fujii Masao
