Re: fork/exec patch: pre-CreateProcess finalization
От | Claudio Natoli |
---|---|
Тема | Re: fork/exec patch: pre-CreateProcess finalization |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B0280AC@harris.memetrics.local обсуждение исходный текст |
Ответ на | fork/exec patch: pre-CreateProcess finalization (Claudio Natoli <claudio.natoli@memetrics.com>) |
Ответы |
Re: fork/exec patch: pre-CreateProcess finalization
Re: fork/exec patch: pre-CreateProcess finalization |
Список | pgsql-patches |
[patch edited + resubmitted for review; not for committing] Hi Tom, figuring that, on balance, you are in fact going to prefer to take a potential future hit in duplicated work (in passing context in the fork/exec case) over moving the client auth code to PostgresMain, I've just gone ahead and made a patch that implements your BackendFork ideas... Please let me know: * if the changes to the BackendFork / SubPostmasterMain logic are more or less what you envisaged, and if you are content with them [Note: we can also roll BackendInit back into BackendFork, making BackendFork (now BackendRun?) pretty much exactly as it was before the fork/exec changes began] * if you are content with the above, whether or not you think I ought to do the same for the SSDataBase logic. I'm hoping for a negative, as the #ifdef logic is not as convoluted as that originally presented in BackendFork (ie. to me, it looks like overkill in this case), but anticipating otherwise :-) Also: * are you ok with the pgstat changes (I'm guessing yes, as you haven't mentioned them, and since these changes are pretty similar to what you suggested for BackendFork) Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Вложения
В списке pgsql-patches по дате отправления: