Re: How should the waiting backends behave in sync rep? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: How should the waiting backends behave in sync rep?
Date
Msg-id AANLkTikmM_8EJm2YyYzJUaUn3qy5VNvfiTu69LbjJtQ-@mail.gmail.com
Whole thread Raw
In response to Re: How should the waiting backends behave in sync rep?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Mar 16, 2011 at 6:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Yeah, I pointed out that SIGINT and SIGTERM are blocked there.
>> But not SIGHUP ;)
>>
>> > We could write a scary bit of code to get around that, but it smells
>> > badly of kludge.
>> >
>> > What do you think we should do?
>>
>> What I'm thinking is to make the waiting backends get out of the wait
>> state if synchronous_standby_names is emptied and configuration file
>> is reloaded. IOW, I'd like to change SyncRepWaitForLSN() so that it
>> calls ProcessConfigFile() when the flag got_SIGHUP is true, and then
>> gets out of the wait loop if there is no name in synchronous_standby_names
>> (i.e., when the variable sync_standbys_defined is FALSE).
>
> I did try that and it didn't work.
>
> If you think it will, I'll try again.

There are two potential problems here.  One is that we don't normally
reload the config file except in between toplevel commands, so doing
it here would be slightly inconsistent.  A bigger problem is that
doing complicated stuff at this particular point in the code is a
really bad idea.  It's too late for the commit to fail, and as I
learned the hard way yesterday while fooling around with it, anything
that throws an ERROR here causes a database-wide PANIC and abnormal
system shutdown.  So doing something as complicated as reloading the
config file doesn't seem like a good idea.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Piyush Newe
Date:
Subject: Rectifying wrong Date outputs
Next
From: Nikhil Sontakke
Date:
Subject: Re: Fwd: index corruption in PG 8.3.13