Re: [HACKERS] Stability questions RE 6.5 and 6.3.2 & 6.3.2 problems
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Stability questions RE 6.5 and 6.3.2 & 6.3.2 problems |
Дата | |
Msg-id | 29816.936797432@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Stability questions RE 6.5 and 6.3.2 & 6.3.2 problems (Jason Venner <jason@idiom.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: