Tom, Thanks for this. I am going to push for reproducing the problem in a test environment. If I have any success, I will follow up with results and more details. __ Marc On Sat, 2005-09-17 at 01:23 -0400, Tom Lane wrote: > Michael Fuhr <mike@xxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
