Hi,

It's me again .... I've compiled up the patch and doing some testing on
the side before we install it on our live system, but something has
happened in the past few days with our live system which is interesting.

Basically, on Saturday I started up another process which does more
queries on the database, and means that it gets hammered even harder than
before. Now, instead of getting one or maybe two postgres failures per
day, we have been getting three to four. We just had two in the morning
already.

So this is interesting because I have a good test case now, and also
supports Tom Lanes comments about exceeding the 256 locks thing and
causing problems to occur.

I think by adding this new process to my system, I've caused the chance of
exceeding this 256 value to be increased, making the system more
unreliable. Note that this process is read only, and there are no LOCK
statements in it, but it still allocates read locks I guess, so it would
be causing this to happen.

Ok, well we're testing still, but I'll have some info about when we put it
live in the next few days.

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

Thu, 13 May 1999 11:17:57 +0930 (CST)
Wayne Piekarski <wayne@senet.com.au>
Information about backend waiting