Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-07 09:47:20
Message-ID: AANLkTik4tuG2EA6oeiov1=DO6UcDoARP45Lk+KGfy7HC@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Mon, Mar 7, 2011 at 6:30 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, 2011-03-07 at 17:44 +0900, Fujii Masao wrote:
>
>> The above check should be required also after pg_ctl reload since
>> synchronous_standby_names can be changed by SIGHUP?
>> Or how about just removing that? If the patch I submitted is
>> committed,empty synchronous_standby_names and max_wal_senders = 0
>> settings is no longer unsafe.
>
> Ah, on reload. I plugged the gap only at startup.
>
> I'll fix by changing assign_synchronous_standby_names(), not by changing
> lots of other parts of code and making runtime check each COMMIT.

I don't think that the check of local variable for each COMMIT wastes the
cycle so much. Anyway, the reload of the configuration file should not
cause the server to end unexpectedly. IOW, GUC assign hook should
use GUC_complaint_elevel instead of FATAL, in ereport. The attached
patch fixes that, and includes two typo fixes.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment: use_guc_complaint_elevel_v1.patch
Description: application/octet-stream (2.2 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Thom BrownDate: 2011-03-07 09:57:18
Subject: Sync rep doc corrections
Previous:From: Heikki LinnakangasDate: 2011-03-07 09:31:22
Subject: Re: Composite Index Structure

pgsql-committers by date

Next:From: Fujii MasaoDate: 2011-03-07 11:21:39
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Simon RiggsDate: 2011-03-07 09:30:35
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group