Обсуждение: EXEC_BACKEND

Поиск
Список
Период
Сортировка

EXEC_BACKEND

От
Simon Riggs
Дата:
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



Re: EXEC_BACKEND

От
Tom Lane
Дата:
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


Re: EXEC_BACKEND

От
Simon Riggs
Дата:
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



Re: EXEC_BACKEND

От
Bruce Momjian
Дата:
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

Re: EXEC_BACKEND

От
Magnus Hagander
Дата:
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



Re: EXEC_BACKEND

От
Bruce Momjian
Дата:
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. +


Re: EXEC_BACKEND

От
Simon Riggs
Дата:
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