Re: fork/exec patch - Mailing list pgsql-patches

Neil Conway wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Let me add that Claudio is doing a fantastic job on this.  The
> > changes are minimal and clean.  I think the writing of a per-backend
> > temp file has allowed this patch to be smaller than it might have
> > been.
>
> Did we REALLY conclude that the best way to work around the lack of
> fork() on Win32 is by writing variables out to disk and reading them
> back in? Frankly, that seems like an enormous kludge.
>
> For example, couldn't we write this data into a particular location in
> shared memory, and then pass that location to the child? That is still
> ugly, slow, and prone to failure (shmem being statically sized), but
> ISTM that the proposed implementation already possesses those
> attributes :-)

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.  Of course, this one is
per-backend.

Yea, we could use shared memory for this too, but I don't see a problem
with using the file system.  Older releases of PostgreSQL read from
postgresql.conf or pg_hba.conf or other files for every connection so I
don't see that using the file system is going to be that slow.  Of
course, we removed those file reads because they were slow, but they
were also much larger and more complex in requiring parsing and stuff,
while this is just a list of binary values.  We also have a GUC dump
file that is read by exec too.

The downside of shared memory is that you would need the postmaster to
write into shared memory and you have to allocate enough shared memory
for all backends, but clearly it could be done.  You could just pass the
backend slot number to the child and the child could read from the
offset.  Not sure how to cleanly do the GUC dump file because it is of
variable length depending on the number of GUC variables changed.

I guess the big question is whether it is worth doing in shared memory.
We also would have to pass the shared memory address to the child, and
make sure the child knew the proper offset in shared memory to find its
values.

Of course, stuff that is variable length would be a problem in shared
memory, and we have some of those for the GUC defaults.

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