Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Sun, Dec 14, 2003 at 06:53:22PM -0500, Tom Lane wrote:
> >> You can hardly claim that "no one had issues with that".
>
> > Don't the FSM and the system catalog cache use a similar mechanism?
>
> FSM uses a backing file to hold information over a database shutdown
> (write once during shutdown, read once during startup). That's a little
> different from once per backend fork. Also, there are no race
> conditions to worry about, and finally the system does not *require* the
> backing file to be either present or correct.
>
> The catalog cache uses a file that typically gets updated once per
> VACUUM. Again, the file does not have to be present, nor correct.
> There are mechanisms in place to deal with the cases (including race
> conditions) where it's broken or obsolete.
>
> I have not looked at the proposed fork/exec code in any detail, but
> IIUC it will be *necessary* that the intermediate file be present, and
> correct. I think a minimum requirement for accepting this solution is a
> sketch of how race conditions will be dealt with (ie, postmaster changes
> its own value of some variable immediately after making the temp file).
> I don't necessarily say that the first-cut patch has to get it right,
> but we'd better understand how we will get to where it is right.
Agreed, added to the Win32 status page:
* remove per-backend parameter file and move into shared memory
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
