Re: Pre-forking backend - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Pre-forking backend
Date
Msg-id Pine.LNX.4.21.0109301917250.14768-100000@linuxworld.com.au
Whole thread Raw
In response to Re: Pre-forking backend  (sean-pgsql-hackers@chittenden.org)
Responses Re: Pre-forking backend
List pgsql-hackers
On Sat, 29 Sep 2001 sean-pgsql-hackers@chittenden.org wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > How hard would it be to pre-fork an extra backend
> > 
> > How are you going to pass the connection socket to an already-forked
> > child process?  AFAIK there's no remotely portable way ...
> 
> Umm... Apache?  They use a preforking model and it works quite well for 
> every *NIX that Apache runs on.  ;)  Maybe RSE can comment on this 
> further... -sc

It works very good for what Apache requires. Namely, to have a queue of
processes ready to serve pages. Its not that simple with PostgreSQL - as
the discussion so far has drawn out - since there is no simple way to
guarantee that the 'right' child gets the socket. The reason why there
needs to be a 'right' child is that a socket needs to be passed to a child
which has started up for a given database. Otherwise, there's no benefit.

This aside, isn't it possible to just copy the socket and some
data about the database required into shared memory and have the preforked
children pick the socket up from there. Combined with a framework which
tests that there are still idle pre-forked children waiting for this
database and some configuration options to allow users to specify a number
of waiting backends for a given database, and this would work pretty well.

Gavin



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Glitch in handling of postmaster -o options
Next
From: Tatsuo Ishii
Date:
Subject: PL/pgSQL bug?