On Mon, 2011-03-07 at 17:27 +0900, Fujii Masao wrote:
> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> And,, I found one bug ;) You seem to have wrongly removed the check
> of max_wal_senders in SyncRepWaitForLSN. This can make the
> backend wait for replication even if max_wal_senders = 0. I could produce
> this problematic situation in my machine. The attached patch fixes this problem.

There may be a bug, but that's not the fix.

I spotted that issue myself in testing. I put in a protection to stop
setting synchronous_standby_names if max_wal_senders is zero, with error
message.

Are you saying the committed version doesn't trigger that ERROR?

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 

In response to

• Re: pgsql: Efficient transaction-controlled synchronous replication. at 2011-03-07 08:27:16 from Fujii Masao

Responses

• Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. at 2011-03-07 09:28:25 from Fujii Masao

pgsql-hackers by date

Next:	From: Fujii Masao	Date: 2011-03-07 09:28:25
	Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:	From: Nick Raj	Date: 2011-03-07 09:11:25
	Subject: Re: Composite Index Structure

pgsql-committers by date

Next:	From: Fujii Masao	Date: 2011-03-07 09:28:25
	Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:	From: Heikki Linnakangas	Date: 2011-03-07 08:47:49
	Subject: pgsql: Document the DEFERRABLE option in SET TRANSACTION command.