Re: Pre-forking backend

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: sean-pgsql-hackers(at)chittenden(dot)org
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pre-forking backend
Date: 2001-09-30 10:12:20
Message-ID: Pine.LNX.4.21.0109301917250.14768-100000@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 29 Sep 2001 sean-pgsql-hackers(at)chittenden(dot)org wrote:

> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2001-09-30 12:13:02 PL/pgSQL bug?
Previous Message Jan Wieck 2001-09-30 04:40:49 Re: Pre-forking backend