Re: "PANIC: could not open critical system index 2662" - twice
Kirk Wolak <wolakk@gmail.com>
From: Kirk Wolak <wolakk@gmail.com>
To: Evgeny Morozov <postgresql3@realityexists.net>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL General <pgsql-general@postgresql.org>
Date: 2023-05-16T19:54:02Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Handle DROP DATABASE getting interrupted
- f66403749df7 15.4 landed
- 1c38e7ae17b6 11.21 landed
- 034a9fcd2bb8 12.16 landed
- 81ce000067e3 13.12 landed
- d11efe830385 14.9 landed
- a4b4cc1d60f7 16.0 landed
- c66a7d75e652 17.0 landed
-
Remove the restriction that the relmap must be 512 bytes.
- d8cd0c6c95c0 16.0 cited