Re: Unable to startup postgres: Could not read from file"pg_clog/00EC"

Поиск
Список
Период
Сортировка
От Nick Renders
Тема Re: Unable to startup postgres: Could not read from file"pg_clog/00EC"
Дата
Msg-id 27313D00-F925-4471-91F3-1D14084E3B25@arcict.com
обсуждение исходный текст
Ответ на Re: Unable to startup postgres: Could not read from file"pg_clog/00EC"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Unable to startup postgres: Could not read from file "pg_clog/00EC"
Список pgsql-general
Thank you for the feedback, Alvaro.

Unfortunately, the database is no longer "dumpable". We were able to do 
a pg_dump yesterday morning (12 hours after the crash + purging the 
pg_clog) but if we try one now, we get the following error:

    unexpected chunk number 1 (expected 0) for toast value 8282331 in 
pg_toast_38651

Looking at our data, there seem to be 6 tables that have corrupt 
records. Doing a SELECT * for one of those records, will return a 
similar error:

    missing chunk number 0 for toast value 8288522 in pg_toast_5572299


What is the best way to go from here? Is tracking down these corrupt 
records and deleting them the best / only solution?
Is there a way to determine of there are issues with new data (after the 
crash)?

Any help and advice is very much appreciated.

Thanks,


Nick Renders


On 5 Feb 2020, at 12:51, Alvaro Herrera wrote:

> On 2020-Feb-05, Nick Renders wrote:
>
>> Is there anything specific I should check in our postgres 
>> installation /
>> database to make sure it is running ok now? Anyway to see what the
>> consequences were of purging that one pg_clog file?
>
> Losing pg_clog files is pretty bad, and should not happen; then again,
> this might have been something else (ie. the file was maybe not lost).
> That said, wrongly overwriting files is even worse.
>
> By zeroing an existing pg_clog file, you marked a bunch of 
> transactions
> as aborted.  Your data is now probably inconsistent, if not downright
> corrupt.  I would be looking for my most recent backup ...
>
> If you're very lucky, your database might be pg_dumpable.  I would try
> that, followed by restoring it in a separate clean instance and seeing
> what happens.
>
> -- 
> Álvaro Herrera                https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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