Re: GUC patch for Win32 - Mailing list pgsql-patches

From Tom Lane
Subject Re: GUC patch for Win32
Date
Msg-id 7959.1051848865@sss.pgh.pa.us
Whole thread Raw
In response to Re: GUC patch for Win32  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: GUC patch for Win32  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Where exactly is the interlock to ensure that the new backend will end up
>> with the correct settings if someone is changing the values at about
>> the time of the fork?

> Postmaster creates a new file, then does rename() to move it to the name
> used by the backends.  It can't move it until the file is not in use.

And?

How exactly does that guarantee that the new backend will see an update
occurring at about the same time?  I'm pretty sure that GUC is fired up
before backends start listening to signals (and that's assuming the
Windows port has a Unixy idea of signal response, which I seem to recall
you telling me wasn't the case).

            regards, tom lane


pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: GUC patch for Win32
Next
From: Bruce Momjian
Date:
Subject: Re: GUC patch for Win32