Re: data file corruption

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: data file corruption
Дата
Msg-id 15103.1369315348@sss.pgh.pa.us
обсуждение исходный текст
Ответ на data file corruption  (PG User <pguser1982@gmail.com>)
Ответы Re: data file corruption  (PG User <pguser1982@gmail.com>)
Список pgsql-general
PG User <pguser1982@gmail.com> writes:
> ... Later we found that invalid header is actually valid header for other
> table's data file. So somehow data of one table got inserted into another
> and both tables have different # of attributes. Can this be possible? Any
> hardware issue can cause this?

There are (at least) 3 possibilities:

1. Postgres got confused and wrote a block to the wrong place.

2. The kernel (filesystem) got confused and wrote a block to the wrong
place.

3. The disk hardware got confused and wrote a block to the wrong place.

The easiest way to narrow it down would be to try to identify the size
of the misplaced write.  If postgres messed up, it'd certainly have
written a whole 8K page to the wrong place.  A filesystem bug would more
likely have misplaced a single filesystem block, which might be 8K but
I think it's more usually 1K or 4K on modern machines (a little research
about your OS should tell you what blocksize is being used on this
filesystem).  Or if the disk screwed up, it'd most likely have misplaced
a single 512-byte sector.  So take a closer look at the pg_filedump
results for the questionable page, and see if you can determine how much
of the page looks to have been interpolated from someplace else.

FWIW, if I had to bet with no further data, I'd bet on door #2.
Bugs of this sort have been found in Postgres, but not in a long time.
Is your kernel up-to-date?

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: salah jubeh
Дата:
Сообщение: Re: What is a DO block for?
Следующее
От: Dev Kumkar
Дата:
Сообщение: Re: [ODBC] ODBC constructs