Re: pg_ctl reload breaks our client

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Marc Munro <marc(at)bloodnok(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: pg_ctl reload breaks our client
Date: 2005-09-17 05:23:33
Message-ID: 5097.1126934613@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Fri, Sep 16, 2005 at 04:34:46PM -0700, Marc Munro wrote:
>> On Fri, 2005-09-16 at 17:10 -0600, Michael Fuhr wrote:
>> This is not currently seen as a priority (the work-around of "don't do
>> that" is seen as sufficient). I'm simply hoping to get someone to say
>> for sure that the client app should not be able to tell that a reload
>> has happened. At that point I may be able to raise the priority of this
>> issue.

> As far as I know clients shouldn't notice a reload (which is effected
> via a SIGHUP); I just did some tests and didn't see any problems.

Existing client connections should not be able to notice a reload that
changes pg_hba.conf or pg_ident.conf; however they definitely *should*
notice a reload that changes postgresql.conf (at least for parameters
that aren't overridden by other cases, such as a SET in the current
session). So the blanket statement Marc is making is simply wrong.

Whether there is a bug here is impossible to say given the limited
amount of information provided. I'd not expect a reload to cause
an existing connection to become totally dysfunctional, which is
what Marc seems to be claiming ... but without more evidence or
a test case, there's not much to be done.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Greg Stark 2005-09-17 05:36:50 Re: Duplicate Values or Not?!
Previous Message Tom Lane 2005-09-17 05:11:55 Re: Setting WHERE on a VIEW with aggregate function.