From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | CSN <cool_screen_name90001(at)yahoo(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Various serverlog messages |
Date: | 2003-07-04 06:19:43 |
Message-ID: | 13487.1057299583@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
CSN <cool_screen_name90001(at)yahoo(dot)com> writes:
> Yes, pg_dump and pg_dumpall appear to work fine. The
> output for all of the dbs (except one) for the select
> above is:
> [ normal looking ]
> Here's the exception:
> 16656 | pg_toast_16384_index | 99 | 0
> | 1 | 403 | 3682590432 | 1 |
> 0 | 0 | 0 | f | f
> | i | 2 | 0 | 0
> | 0 | 0 | 0 | f | f
> | f | f |
> (1 row)
Sure enough, the relfilenode column (which determines the actual on-disk
filename) is clobbered. Weird as can be ... could you have suffered a
hardware glitch affecting just that one word? Doesn't seem real likely
--- the glitches I've seen in the past tend to take out more than a word
at a time. But it's not easy to credit as a software error either.
You could fix this database with a quick UPDATE command to set
relfilenode back to what it should be in this pg_class row. However,
it'd be wise to wonder what other issues might be lurking. If I were
you I'd do a pg_dumpall/initdb/reload cycle, and also spend some time on
hardware testing (if you're on Intel hardware, memtest86 has a good
reputation for finding RAM problems, and people have successfully found
disk problems with badblocks).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Weiping He | 2003-07-04 06:52:41 | any body using Solaris8 with postgresql 7.3.3 |
Previous Message | Henrik Steffen | 2003-07-04 06:05:40 | Re: Still trouble reindexing |