From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jdassen(at)cistron(dot)nl |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | RE: Re: PostgreSQL; Strange error |
Date: | 2001-03-20 18:18:49 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3334@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> >> Warning: PostgreSQL query failed: FATAL 1: my bits moved
> >> right off the end of the world! Recreate index
> >> pg_attribute_relid_attnum_index.
>
> This is an internal "can't happen" failure condition,
> presumably arising from some weird corner-case bug in btree
> index manipulation. We have seen sporadic reports of this
> failure, mostly from people using lots of large objects,
> but no one has yet provided a test case that allows
> the problem to be reproduced from scratch. When I'm in an
Just use gdb to prevent parent btree page update after
split and you'll get that error next time when splitting
new, unpointed from parent, right sibling.
In real life you have !0 probability to get same case
without gdb just by pg_ctl -m fast stop, not to mention
pg_ctl -m immediate stop, power off and OS' crash.
> optimistic mood I think that the bug might be fixed in 7.1,
> but it's hard to say for sure because I've never seen this
> failure happen myself.
Just add elog(ERROR) after split to see this.
This is what I made to test new btree runtime recovery code
in 7.1.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Frank | 2001-03-20 18:28:21 | RE: Backing up postgresql databases |
Previous Message | Tim Frank | 2001-03-20 18:17:43 | Re: Backing up postgresql databases |