Re: [PATCHES] Reorganization of spinlock defines - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: [PATCHES] Reorganization of spinlock defines
Date
Msg-id 20030912105540.H82880@ganymede.hub.org
Whole thread Raw
In response to Re: [PATCHES] Reorganization of spinlock defines  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Reorganization of spinlock defines  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [PATCHES] Reorganization of spinlock defines  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Fri, 12 Sep 2003, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> >> If we force people to give a --without-spinlocks config option to build
> >> that way, then `pg_config --configure' will reveal the dirty deed ...
>
> > That's not quite what I meant :)  Right now, if I understood what Bruce
> > was saying, if someone doesn't have spinlocks, it switches to using SysV
> > Messenging, correct?  In the current system, is there anything that one
> > can do on a running, live system, to detect that you aren't using
> > spinlocks?
>
> It'll be fairly obvious if you use "ipcs -s" and count up the number of
> semaphores created by the postmaster.  Ordinarily we will grab
> approximately max_connections semas, but without spinlocks it will
> be somewhere north of max_connections + 2 * shared_buffers ...

'K, now, I know we acquire all our shared_buffers on startup now ... do we
do the same with semaphores?  Or do they only grow as connections grow?
If we do acquire at the start, would it not be trivial to add a message to
the startup messages, based on #_of_semaphores != max_connections, that
tells ppl that spinlocks aren't being used?


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Reorganization of spinlock defines
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Reorganization of spinlock defines