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