BUG #5976: Corrupted pages on the production database

Поиск
Список
Период
Сортировка
От Vlad Arkhipov
Тема BUG #5976: Corrupted pages on the production database
Дата
Msg-id 201104130352.p3D3q78B094334@wwwmaster.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #5976: Corrupted pages on the production database  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-bugs
The following bug has been logged online:

Bug reference:      5976
Logged by:          Vlad Arkhipov
Email address:      arhipov@dc.baikal.ru
PostgreSQL version: 9.0.3
Operating system:   Red Hat 4.1.2-48, 64-bit
Description:        Corrupted pages on the production database
Details:

I have recently encounter a problem with the production database. Eventually
pg_dump could not be done.

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  could not access status of
transaction 3499806839
DETAIL:  Could not open file "pg_clog/0D09": No such file or directory.
pg_dump: The command was: COPY rolap.agg_lab_invests_registration_month
(service, invest, sampling_place, material, status, rejection_reason,
registration_month, container_type, device, registration_period_1,
execution_period_1, authorization_period_1, overdue_period_1,
completion_period_1, fact_count, quantity, profile_count, service_count,
container_count, reg_period, exec_period, auth_period, over_period,
comp_period) TO stdout;

A simple SELECT * FROM rolap.agg_lab_invests_registration_month raises the
same error.

There is also a stand-by server (streaming replication) which does not have
this error. I've elaborated on this issue a bit and found 2 corrupted pages
in the file of relation. The first one is semi-corrupted, one half of it is
correct, but another part contains data from another database table. The
second one is completely corrupted and contains data from the same table as
the corrupted part of the first page.

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: BUG #5973: erreur SERIAL 4
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] PostgreSQL backend process high memory usage issue