Re: fork/exec

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: fork/exec
Date: 2003-11-30 15:48:45
Message-ID: 200311301548.hAUFmjA26427@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

Claudio Natoli wrote:
>
>
> > Oh, good. I couldn't remember if it was the postmaster or child that
> > validates that key. I now remember only the postmaster needs
> > the secret because it sends the signal. Not sure what random seed Claudio
> was
> > asking about. Probably GUC's "seed" parameter --- Claudio, that is
> > already covered in that GUC binary file I create that I
> > mentioned in an earlier email.
>
> Ah. I was only talking about the random "seed" insofar as it is one of a
> number of things that are done inside BackendFork (ie. which currently occur
> in between the fork call, and the call to PostgresMain).
>
> Specifically, ISTM that, working on the assumption that the future exec call
> will "replace" the existing call to PostgresMain, then in order to get the
> fork/exec model in the best shape for porting to Win32 the code which
> currently falls betweens fork/BackendFork + exec needs to be minimalized as
> far as possible. It was this reasoning that prompted the second
> point/question at the start of this thread...

Yep, each backend has a random secret used for query cancel, and we will
have to find a way to pass that to the child so the child can sent it to
the client.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2003-11-30 17:30:11 Re: fork/exec
Previous Message Bruce Momjian 2003-11-30 15:47:27 Re: fork/exec