From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Ken Hirsch <kenhirsch(at)myself(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pre-forking backend |
Date: | 2001-09-29 20:29:44 |
Message-ID: | 200109292029.f8TKTiR23997@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian wrote:
> > Tom Lane 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 ...
> >
> > No idea but it seemed like a nice optimization if we could do it.
>
> What can be done is to have the parent process open and listen() on the
> socket, then have each child do an accept() on the socket. That way you
> don't have to pass the socket. The function of the parent process would then
> be only to decide when to start new children.
>
> On some operating systems, only one child at a time can accept() on the
> socket. On these, you have to lock around the call to accept().
But how do you know the client wants the database you have forked? They
could want a different one.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-09-29 20:50:22 | Re: Pre-forking backend |
Previous Message | Ken Hirsch | 2001-09-29 20:28:00 | Re: Pre-forking backend |