On Sun, Feb 22, 2009 at 1:53 PM, wrote:
> Greetings,
>
>
>
> I had a hardware problem this morning, which I believe is now resolved, but
> I seem to have a little database corruption issue. This is what I am seeing
> when I restart postgres:
>
> PANIC: right sibling's left-link doesn't match
>
ken.col...@sage.com writes:
> I had a hardware problem this morning, which I believe is now resolved, but
> I seem to have a little database corruption issue. This is what I am seeing
> when I restart postgres:
> PANIC: right sibling's left-link doesn't match
8.2.6 and later provide a little more
Greetings,
I had a hardware problem this morning, which I believe is now resolved, but
I seem to have a little database corruption issue. This is what I am seeing
when I restart postgres:
PANIC: right sibling's left-link doesn't match
So I attempted to reindex the database and now I ge
I'm running ubuntu and can see references to only one log file which i'm
assuming is the postmaster log..
Anyway the only relevant bits are:
GMT LOG: relation "pg_class" TID 15538/4: dead HOT-updated tuple ---
cannot shrink relation
2009-02-12 21:06:40 GMT STATEMENT: VACUUM FULL VERBOSE ANA
John Lister writes:
> I seem to have more dead rows now..
> doing a vacuum full on pg_class gives me
> INFO: vacuuming "pg_catalog.pg_class"INFO: "pg_class": found 37
> removable, 1845 nonremovable row versions in 18905 pages
> DETAIL: 27 dead row versions cannot be removed yet.
> Nonremovabl
I seem to have more dead rows now..
doing a vacuum full on pg_class gives me
INFO: vacuuming "pg_catalog.pg_class"INFO: "pg_class": found 37
removable, 1845 nonremovable row versions in 18905 pages
DETAIL: 27 dead row versions cannot be removed yet.
Nonremovable row versions range from 160
Sorry, had exported it - bad cut/pasting...
I even tried it in single-user mode passing -P directly but got the same
result
Also confused/concerned by the 7 dead rows in pg_class. as i've
restarted the server all transaction should have finished so i'd like to
reclaim these - especially as vacu
John Lister writes:
> still getting the same problem.
>>> PGOPTIONS="-P"
>>> psql backend
I think you need export PGOPTIONS="-P" to make that work. Whether
it's related to your problem isn't clear though.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-a
>Yeah, if you have reason not to trust the system indexes then -P is
>a good idea until they are fixed. Standalone mode per se isn't that
>important --- you could do this from a regular session with -P specified
>via PGOPTIONS.
still getting the same problem.
> PGOPTIONS="-P"
> psql backend
>>
John Lister writes:
> Although saying that..
> reindex now works, but doing a vacuum verbose complains that the index
> is out of step with the table and i should reindex..
> would i be better shutting the db down, restarting in standalone mode
> (and also using the -P option) before reindexing
Cheers tom, that did it - i've removed the duplicates and seeing what else
is broken.
.
"John Lister" writes:
ERROR: could not create unique index "pg_class_oid_index"
a quick inspection of the pg_class table doesn't show any duplicates, is
there anyway i can find out which row(s) are d
"John Lister" writes:
> ERROR: could not create unique index "pg_class_oid_index"
> a quick inspection of the pg_class table doesn't show any duplicates, is
> there anyway i can find out which row(s) are duplicated and remove them
> without a full db restore?
> also doing something like this
Hi, my wal archiving broke and postgresql filled up the local disk with
transaction logs, which i foolishly deleted in a moment of madness, after
resetting the transaction log a few of my tables are damaged but repairable.
However the system tables also seemed to have suffered. My main problem i
13 matches
Mail list logo
