Re: [HACKERS] Stability questions RE 6.5 and 6.3.2 & 6.3.2 problems

Jason Venner <jason@idiom.com> writes:
> This is an error I am getting with 6.3.2
> under freebsd 2.2.8
> Mon Sep 6 16:44:48 BST 1999: NOTICE: SIAssignBackendId: discarding tag 2147483020

I believe this is a symptom of running out of per-backend slots in the
SI (shared inval) communication area.  Theoretically that should not
happen until you try to start the 65th concurrent backend.

> We do have about 20 - 30 simultaneous connections.

Could it be getting up to a peak of 65 or more?

You could try increasing MaxBackendId in include/storage/sinvaladt.h,
but a much better answer is to update to 6.5, which supports easy
alteration of the max number of backends (and doesn't die horribly
when you hit the limit, either).

> We do not use any large objects (since they caused constant backend
> crashes for us)

Quite a few large-object bugs have been fixed since 6.3.2.  In fact,
quite a few bugs of many descriptions have been fixed since 6.3.2.

> 2) is 6.5 stable enough for 23.5x7 production applications.

Much more so than 6.3.2, for sure.  You should actually use 6.5.1,
or wait a few more days for 6.5.2 which has a few more bugs fixed
(or grab the 6.5.2 beta tarball from a week or so back, or pull the
REL6_5_PATCHES branch from the CVS repository).

> 3) are large objects stable in 6.5 (where I can store and access
> 20,000 of them regularily)

They're stable, but 20000 of them will be pretty slow (you'll end up
with 40000 separate files in your DB directory :-().  There has been
talk of fixing this by keeping multiple large objects in one file,
but I'd rather see the effort go into allowing tuples larger than
one disk block, which would eliminate the need for large objects
altogether...

> 4) if all my sql works in 6.3.2 will it need any changes to run under 6.5

Should pretty much work.  There are a few gotchas such as words that
are reserved keywords now that weren't before --- you might have to
rename some fields or tables, or resign yourself to double-quoting
those names all the time.  (I got caught with a field named
"timestamp", for example.)

You might also want to redesign whatever cross-client locking scheme
you are using.  I'm in the middle of that for my company --- we used
to just do "BEGIN; LOCK TABLE primary_table; blah blah blah; END;"
in each client to ensure that concurrent updates to several distinct
tables never caused deadlocks or apparent inconsistencies.  While that
still *works* under 6.5, you can get a heck of a lot more concurrency
if you understand and exploit the MVCC features.


I'd recommend bringing up a test 6.5 installation in parallel with your
6.3.2 installation (just give it a different install directory and
port number) so that you can experiment before you commit to a
changeover.  But do make the upgrade.  6.4 was a big win over 6.3.2
for stability in my applications, and 6.5 is better.
        regards, tom lane