Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-07T09:28:25Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Efficient transaction-controlled synchronous replication.
- a8a8a3e09652 9.1.0 cited
On Mon, Mar 7, 2011 at 6:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Mon, 2011-03-07 at 17:27 +0900, Fujii Masao wrote: >> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs <simon@2ndquadrant.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? I changed synchronous_standby_names after startup and reloaded the configuration file. So I didn't encounter such an error message. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center