Обсуждение: Re: fork/exec

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

Re: fork/exec

От
Claudio Natoli
Дата:

> 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...

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>

Re: fork/exec

От
Bruce Momjian
Дата:
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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073