Re: Various serverlog messages
От | Tom Lane |
---|---|
Тема | Re: Various serverlog messages |
Дата | |
Msg-id | 13487.1057299583@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Various serverlog messages (CSN <cool_screen_name90001@yahoo.com>) |
Ответы |
Re: Various serverlog messages
|
Список | pgsql-general |
CSN <cool_screen_name90001@yahoo.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
В списке pgsql-general по дате отправления: