Re: fork/exec patch: pre-CreateProcess finalization
От | Tom Lane |
---|---|
Тема | Re: fork/exec patch: pre-CreateProcess finalization |
Дата | |
Msg-id | 26038.1072457314@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | fork/exec patch: pre-CreateProcess finalization (Claudio Natoli <claudio.natoli@memetrics.com>) |
Ответы |
Re: fork/exec patch: pre-CreateProcess finalization
|
Список | pgsql-patches |
Claudio Natoli <claudio.natoli@memetrics.com> writes: > This has required some reworking of the existing code base, particularly to > BackendFork (which now actually does the fork()). As such, I've been > anticipating that this will be the most controversial of the fork/exec > patches, so critique away :-) You haven't explained why that's necessary. Given the fact that this patch seems to hugely complicate the postmaster logic --- not so much either path individually, but the messy #ifdef interleaving of two radically different programs --- I am inclined to reject it on style grounds alone. We should either find a way to make the fork/exec path more like the existing code, or bite the bullet and change them both. Doing it the way you have here will create an unmaintainable mess. I'm not prepared to work on a postmaster in which a step as basic as fork() happens in two different places depending on an #ifdef. If you want to change them both, let's first see the reason why it's necessary. regards, tom lane
В списке pgsql-patches по дате отправления: