Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

Added to TODO:
* Consider increasing internal areas when shared buffers is increased
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php


---------------------------------------------------------------------------

Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > Now that I've got a little better idea of what this code does, I've
> > noticed something interesting... this issue is happening on an 8-way
> > machine, and NUM_SLRU_BUFFERS is currently defined at 8. Doesn't this
> > greatly increase the odds of buffer conflicts? Bug aside, would it be
> > better to set NUM_SLRU_BUFFERS higher for a larger number of CPUs?
> 
> We had talked about increasing NUM_SLRU_BUFFERS depending on
> shared_buffers, but it didn't get done.  Something to consider for 8.2
> though.  I think you could have better performance by increasing that
> setting, while at the same time dimishing the possibility that the race
> condition appears.
> 
> I think you should also consider increasing PGPROC_MAX_CACHED_SUBXIDS
> (src/include/storage/proc.h), because that should decrease the chance
> that the subtrans area needs to be scanned.  By how much, however, I
> wouldn't know -- it depends on the number of subtransactions you
> typically have; I guess you could activate the measuring code in
> procarray.c to get a figure.
> 
> -- 
> Alvaro Herrera                 http://www.amazon.com/gp/registry/CTMLCN8V17R4
> www.google.com: interfaz de l?nea de comando para la web.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +