Re: "PANIC: could not open critical system index 2662" - twice
| От | Kirk Wolak |
|---|---|
| Тема | Re: "PANIC: could not open critical system index 2662" - twice |
| Дата | |
| Msg-id | CACLU5mQ_qvU6WTeBz2oQZXXwXY9auDscXGueV5407ii1UJMhRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: "PANIC: could not open critical system index 2662" - twice (Evgeny Morozov <postgresql3@realityexists.net>) |
| Список | pgsql-general |
On Tue, May 16, 2023 at 10:20 AM Evgeny Morozov <postgresql3@realityexists.net> wrote:
On 9/05/2023 3:32 am, Andres Freund wrote:
> Attached is a rough prototype of that idea (only using datconnlimit ==
> -2 for now).
> I guess we need to move this to -hackers. Perhaps I'll post subsequent
> versions below
> https://www.postgresql.org/message-id/20230314174521.74jl6ffqsee5mtug%40awork3.anarazel.de ?
So now that a patch is in the works, can I drop the two corrupted
databases? Is there a workaround I can use to reduce the risk of running
into this issue again until a patch is released? (Which I guess would be
in August?)
The only work around to avoid losing data that I know of are backups and WAL backups.
Plus "hard core testing/validation" that they work. We settled on pg_backrest and are happy with it.
Technically, based on what I understand of this bug. It did not corrupt the WAL. If that's true, then if
you had a basebackup and all the wall files, you could have played back and recovered the data.
At least to some degree. Assuming I am right.
HTH
В списке pgsql-general по дате отправления: