Karl, Doug - could you try new vacuum code (should be in current snapshot
already) ?
Did you use CASSERT in compilation ?
Please try re-compile with this if not.
Also, Doug, could you post me EXPLAIN output of your UPDATE query (below) ?

TIA,
Vadim

Karl Denninger wrote:
That's the same problem, but I don't get it during use - only during the
vacuum.

I've got a LOT of large tables - the only one which is doing this to me is
the one which has a compound unique index - the problem may lie there.

On Mon, Feb 09, 1998 at 11:59:47AM -0800, Doug Mitchell wrote:

I have a 200-300 MB table that also seems to be having index corruption
problems. It also has a four-field unique index. I removed the old
database, did an initdb and a reload. Everything works fine until I let
several clients update the table at the same time. Once I let several
clients work concurrently, the index seems to get "corrupted".
If I had to guess, I'd say that something was not getting locked correctly.
Were you running vacuum while the table was being accessed?

mybase=> UPDATE sometable SET lasttime = now () WHERE ... ;
FATAL 1: btree: BTP_CHAIN flag was expected

I'm running a fairly recent snapshot:
2916657 Feb 2 00:02 postgresql.snapshot.tar.gz

Has anyone else seen this problem with big tables or under heavy concurrent
access?

Thanks,
Doug

----------------------------------------------------
At 02:10 PM 2/8/98 -0600, Karl Denninger wrote:
Hi folks,

I'm running into Btree index corruption problems with large (~500MB)
databases.

There is no indication of trouble until I run vacuum - then the system comes
back with a fatal error indicating that a chain in the Btree is invalid, and
stops.

The index in question is a compound index with 4 fields, and is unique as
well.

Any ideas? The scuttlebutt is that hash indices are broken, and besides, in
this case it wouldn't work anyway since I need a unique index on this (which
is restricted to btrees).

This is V6.2.1.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 26, '98 at 12:24p
activeFeb 26, '98 at 12:24p
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Vadim B. Mikheev: 1 post

People

Translate

site design / logo © 2022 Grokbase