> > The interesting thing is, we went and put in another 128 mb of ram (from
> > 256 to 384 now) and recompiled the kernel with more semaphores and shared
> > memory, and the improvement was incredible! Before, we would get semget
> > failures every so often when we had about 50 backends going, causing the
> > whole thing to fall over, but now we get
> > "fmgr_info: function 111257088: cache lookup failed"
> > after 64 backends (which is what we compiled postgres for) which I
> > assume isn't so fatal and the whole system keeps running.
>
> The 6.4.2 code would not allocate all shared memory/semaphores at
> startup, and only fail when you go to a large number of backends. 6.5
> fixes this by allocating it all on startup.
Ok, thats cool ... One question though: is the cache lookup failed message
really bad or is it a cryptic way of saying that the connection is refused
but everything else is cool? I have no problem with the fact that the
connection failed, but does it cause corruption or postgres to fall over
later on? Ie, if you get a semget failure, shortly after the whole thing
will die, possibly causing data corruption or something. Would these kind
of errors cause BTP_CHAIN errors, or is that totally unrelated?
As another general question, if I randomly kill postgres backends during
the middle of transactions, is there a possibility for corruption, or is
it safe due to the way transactions are commited, etc. I've always been
very nervous when it comes to killing backends, as I was worried something
might go wrong, leaving something out of sync.
thanks,
Wayne
------------------------------------------------------------------------------
Wayne Piekarski Tel: (08) 8221 5221
Research & Development Manager Fax: (08) 8221 5220
SE Network Access Pty Ltd Mob: 0407 395 889
222 Grote Street Email: wayne@senet.com.au
Adelaide SA 5000 WWW: http://www.senet.com.au