Thread: EXEC_BACKEND
We keep talking about EXEC_BACKEND mode, though until recently I had misunderstood what that meant. I also realised that I have more than once neglected to take it into account when writing a patch - one recent patch failed to do this. I can't find anything coherent in docs/readme/comments to explain why it exists and what its implications are. The why is "Windows", AFAICS, but the full implications are far from clear in my blissful, mostly Window-less world. Can someone either point me to or write a coherent explanation of this, so that we can add it to the code somewhere handy? I want to make sure that everything I'm working on covers the main points the first time I wrote code. Thanks, -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> We keep talking about EXEC_BACKEND mode, though until recently I had
> misunderstood what that meant. I also realised that I have more than
> once neglected to take it into account when writing a patch - one recent
> patch failed to do this.
> I can't find anything coherent in docs/readme/comments to explain why it
> exists and what its implications are.
It exists because Windows doesn't have fork(), only the equivalent of
fork-and-exec. Which means that no state variables will be inherited
from the postmaster by its child processes, and any state that needs to
be carried across has to be handled explicitly. You can define
EXEC_BACKEND in a non-Windows build, for the purpose of testing code
to see if it works in that environment.
regards, tom lane
On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > We keep talking about EXEC_BACKEND mode, though until recently I had > > misunderstood what that meant. I also realised that I have more than > > once neglected to take it into account when writing a patch - one recent > > patch failed to do this. > > > I can't find anything coherent in docs/readme/comments to explain why it > > exists and what its implications are. > > It exists because Windows doesn't have fork(), only the equivalent of > fork-and-exec. Which means that no state variables will be inherited > from the postmaster by its child processes, and any state that needs to > be carried across has to be handled explicitly. You can define > EXEC_BACKEND in a non-Windows build, for the purpose of testing code > to see if it works in that environment. OK, if its that simple then I see why its not documented. Thanks. I thought there might be more to it than that. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs wrote: > > On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote: > > Simon Riggs <simon@2ndQuadrant.com> writes: > > > We keep talking about EXEC_BACKEND mode, though until recently I had > > > misunderstood what that meant. I also realised that I have more than > > > once neglected to take it into account when writing a patch - one recent > > > patch failed to do this. > > > > > I can't find anything coherent in docs/readme/comments to explain why it > > > exists and what its implications are. > > > > It exists because Windows doesn't have fork(), only the equivalent of > > fork-and-exec. Which means that no state variables will be inherited > > from the postmaster by its child processes, and any state that needs to > > be carried across has to be handled explicitly. You can define > > EXEC_BACKEND in a non-Windows build, for the purpose of testing code > > to see if it works in that environment. > > OK, if its that simple then I see why its not documented. Thanks. I > thought there might be more to it than that. I added a little documentation at the top of postmaster.c::backend_forkexec(). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v retrieving revision 1.564 diff -c -c -r1.564 postmaster.c *** src/backend/postmaster/postmaster.c 23 Sep 2008 09:20:36 -0000 1.564 --- src/backend/postmaster/postmaster.c 23 Sep 2008 20:33:14 -0000 *************** *** 3286,3291 **** --- 3286,3295 ---- /* * backend_forkexec -- fork/exec off a backend process * + * Some operating systems (WIN32) don't have fork() so we have to simulate + * it by storing parameters that need to be passed to the child and + * then create a new child process. + * * returns the pid of the fork/exec'd process, or -1 on failure */ static pid_t
Bruce Momjian wrote: > Simon Riggs wrote: >> On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote: >>> Simon Riggs <simon@2ndQuadrant.com> writes: >>>> We keep talking about EXEC_BACKEND mode, though until recently I had >>>> misunderstood what that meant. I also realised that I have more than >>>> once neglected to take it into account when writing a patch - one recent >>>> patch failed to do this. >>>> I can't find anything coherent in docs/readme/comments to explain why it >>>> exists and what its implications are. >>> It exists because Windows doesn't have fork(), only the equivalent of >>> fork-and-exec. Which means that no state variables will be inherited >>> from the postmaster by its child processes, and any state that needs to >>> be carried across has to be handled explicitly. You can define >>> EXEC_BACKEND in a non-Windows build, for the purpose of testing code >>> to see if it works in that environment. >> OK, if its that simple then I see why its not documented. Thanks. I >> thought there might be more to it than that. > > I added a little documentation at the top of > postmaster.c::backend_forkexec(). Doesn't that make more sense in say, the Developer FAQ? //Magnus
Magnus Hagander wrote: > Bruce Momjian wrote: > > Simon Riggs wrote: > >> On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote: > >>> Simon Riggs <simon@2ndQuadrant.com> writes: > >>>> We keep talking about EXEC_BACKEND mode, though until recently I had > >>>> misunderstood what that meant. I also realised that I have more than > >>>> once neglected to take it into account when writing a patch - one recent > >>>> patch failed to do this. > >>>> I can't find anything coherent in docs/readme/comments to explain why it > >>>> exists and what its implications are. > >>> It exists because Windows doesn't have fork(), only the equivalent of > >>> fork-and-exec. Which means that no state variables will be inherited > >>> from the postmaster by its child processes, and any state that needs to > >>> be carried across has to be handled explicitly. You can define > >>> EXEC_BACKEND in a non-Windows build, for the purpose of testing code > >>> to see if it works in that environment. > >> OK, if its that simple then I see why its not documented. Thanks. I > >> thought there might be more to it than that. > > > > I added a little documentation at the top of > > postmaster.c::backend_forkexec(). > > Doesn't that make more sense in say, the Developer FAQ? I figured I should put it where it is used; the developer's FAQ is for more generalized issues, I feel. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, 2008-09-23 at 16:35 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > > > > > I can't find anything coherent in docs/readme/comments to explain why it > > > > exists and what its implications are. > > > > > > It exists because Windows doesn't have fork(), only the equivalent of > > > fork-and-exec. Which means that no state variables will be inherited > > > from the postmaster by its child processes, and any state that needs to > > > be carried across has to be handled explicitly. You can define > > > EXEC_BACKEND in a non-Windows build, for the purpose of testing code > > > to see if it works in that environment. > > > > OK, if its that simple then I see why its not documented. Thanks. I > > thought there might be more to it than that. > > I added a little documentation at the top of > postmaster.c::backend_forkexec(). Thanks. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support