Thread: Re: [PATCHES] fork/exec patch

pgman wrote:
> Neil Conway wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > I don't think we ever discussed it, but it seemed logical and a minimal
> > > change to the code.  We already have a GUC write of non-default values
> > > for exec and no one had issues with that.
> >
> > For the record, I think that is ugly as well :-)
> >
> > Anyway, I'm not necessarily arguing that using shmem is the right way
> > to go here -- that was merely an off-the-cuff suggestion. I'm just
> > saying that whatever solution we end up with, ISTM we can do better
> > than writing out + reading in a file for /every/ new connection.
>
> [ Moved to hackers and win32.  Discussion is writing postmaster-constant
> and per-backend variables to a file for exec'ed backends to read.]
>
> Sure --- I am all ears.  I am looking for suggestions.  I couldn't think
> of anything better.  I did ask a month ago for ideas on how to do this,
> but got no reply.
>
> One idea I had was to write the postmaster-constant values into one
> file, and the per-backend values into another so you would write less
> data for every backend, but then every backend has to read two files.
> Is that a win?

OK, new idea!  Let's write the postmaster-constant values to a file, and
pass the per-backend variables on the command line using -p like we have
in the current code in CVS.  However, those values include the cancel
key, which has to be a secret.  Maybe we need a per-backend array in
shared memory just for those keys.  The postmaster has to keep those
keys anyway, so moving into shared memory might be the right solution.
Right now the cancel key is stored in the Backend struct along with the
backend pid but that is only in the postmaster.

Does this make sense?  It does remove the pgsql_temp directory we were
going to need in the datadir.

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> ... Maybe we need a per-backend array in
> shared memory just for those keys.  The postmaster has to keep those
> keys anyway, so moving into shared memory might be the right solution.

The postmaster's dependence on the contents of shared memory should
ideally be zero (and it is zero, or nearly so, at the moment).
Otherwise a backend crash that clobbers shared memory poses the risk of
taking down the postmaster as well.  We can't go in that direction.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > ... Maybe we need a per-backend array in
> > shared memory just for those keys.  The postmaster has to keep those
> > keys anyway, so moving into shared memory might be the right solution.
>
> The postmaster's dependence on the contents of shared memory should
> ideally be zero (and it is zero, or nearly so, at the moment).
> Otherwise a backend crash that clobbers shared memory poses the risk of
> taking down the postmaster as well.  We can't go in that direction.

OK, but I think we are going to need shared memory to do signals on
Win32.  Perhaps we should create a second shared memory areas only for
fork/exec to hold the per-backend parameters and the signal stuff ---
that might be the cleanest solution.  Also, we could pass all the exec
parameters on the command line _except_ the cancel key, which must be
secret.

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