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                        |
  [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

Reply via email to