Re: fork/exec patch
От | Tom Lane |
---|---|
Тема | Re: fork/exec patch |
Дата | |
Msg-id | 3836.1071447293@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fork/exec patch (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: fork/exec patch
|
Список | pgsql-patches |
Alvaro Herrera <alvherre@dcc.uchile.cl> 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. regards, tom lane
В списке pgsql-patches по дате отправления: