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

From Craig Ringer
Subject Re: Reporting the commit LSN at commit time
Date
Msg-id 53E43ED6.7010903@2ndquadrant.com
Whole thread Raw
In response to Re: Reporting the commit LSN at commit time  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 08/08/2014 10:58 AM, Fujii Masao wrote:
> 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.

I'm not convinced of that.

That pushes the penalty onto the writer - which now has to wait until
replicas catch up. It has to pay this for every commit, even if actually
failing over to another node is unlikely.

It'd be better to just enable sync rep instead, or it would if we had
all-nodes sync rep.

IMO any waiting needs to be done on the other side, i.e. "Wait until I
am caught up before proceeding" rather than "wait for the other end to
catch up before returning".

Doing it the way you describe would make it nearly useless for enabling
client-side failover in BDR, where half the point is that it can deal
with high latency or intermittently available links to downstream replicas.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Reporting the commit LSN at commit time
Next
From: Michael Paquier
Date:
Subject: Re: Reporting the commit LSN at commit time