Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] - Mailing list pgsql-hackers

From dg@illustra.com (David Gould)
Subject Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Date
Msg-id 9805120603.AA14934@hawk.illustra.com
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
List pgsql-hackers
Bruce Momjian:
> > I was thinking that we would have a pool of ready servers _per_database_.
> > That is, we would be able to configure say 8 servers in a particular DB, and
> > say 4 in another DB etc. These servers could run most of the way through
> > initialization (open catalogs, read in syscache etc). Then they would wait
> > until a connection for the desired DB was handed to them by the postmaster.
> >
>
> OK, but how do you invalidate the catalog items that have changed from
> the startup to the time it gets the client connection?

Same way we always do?

Is there any reason the "ready" servers can't track the Shared Invalidate
cache like any other backend? Maybe they have to time out their wait for a
socket every few seconds and process SI updates, but it should be possible
to make this work. Perhaps not as easy as all that, but certainly doable I
would guess.

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
 and someone who knows less will correct me if I'm right."
               --David Palmer (palmer@tybalt.caltech.edu)

pgsql-hackers by date:

Previous
From: Carlos Navarro Garcia
Date:
Subject: Portals again
Next
From: "Göran Thyni"
Date:
Subject: Re: [HACKERS] mmap and MAP_ANON