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