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

[Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>]

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.