Re: does this look more like a possible bug or more like a possible hardware problem...? (long)

Hi Tom,

> > At one point, I arrived at the following situation:
> > psql:/home/data/megadump.sql:5169: WARNING:  specified item offset is too
> > large
> > psql:/home/data/megadump.sql:5169: PANIC:  failed to add item to the page
> > for "pg_attribute_relid_attnum_index"
>
> Looks like a bug to me.  Can you create a reproducible test case?

Nope.....

Trying the same script on a newly created database doesn't show the problem.
However, I do still have the database that came up with this message, which
is now failing a vacuum full verbose analyse with:

(psql)
INFO:  vacuuming "public.user_pref"
INFO:  "user_pref": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
Nonremovable row versions range from 0 to 0 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 0 bytes.
0 pages are or will become empty, including 0 at the end of the table.
0 pages containing 0 free bytes are potential move destinations.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "user_pref_pkey" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.03 sec.
INFO:  index "user_pref_idx1" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  analyzing "public.user_pref"
INFO:  "user_pref": 0 pages, 0 rows sampled, 0 estimated total rows
ERROR:  catalog is missing 6 attribute(s) for relid 8349771

(log)
2004-03-10 10:10:00 [8207] LOG:  statement: vacuum full verbose analyse;
2004-03-10 10:11:43 [8207] ERROR:  catalog is missing 6 attribute(s) for relid
8349771


The server itself has no particular messages in its log that hint on what went
on, except for the earlier mentioned 'possible clash' of a running
pg_autovacuum. By the way, I have stopped pg_autovacuum by now to avoid any
more changes on this particular database.



--
Best,




Frank.