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.
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
----------------------------------------------------
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.
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.