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. +