Re: "PANIC: could not open critical system index 2662" - twice
Alban Hertroys <haramrae@gmail.com>
From: Alban Hertroys <haramrae@gmail.com>
To: Evgeny Morozov <postgresql3@realityexists.net>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
PostgreSQL General <pgsql-general@postgresql.org>
Date: 2023-04-14T08:42:26Z
Lists: pgsql-general
> On 14 Apr 2023, at 9:38, Evgeny Morozov <postgresql3@realityexists.net> wrote: (…) > I don't know whether ZFS zero-fills blocks on disk errors. As I > understood, ZFS should have been able to recover from disk errors (that > were "unrecoverable" at the hardware level) using the data on the other > two disks (which did not report any errors). Thus, PG should not have > seen any corrupted data (if ZFS was working correctly). > https://unix.stackexchange.com/questions/341614/understanding-the-error-reporting-of-zfs-on-linux > seems to confirm this. Am I misunderstanding something? Your problem coincides with a thread at freebsd-current with very similar data corruption after a recent OpenZFS import: blocks of all zeroes, but also missing files. So, perhaps these problems are related? Apparently, there was a recent fix for a data corruption issue with the block_cloning feature enabled, but people are still seeing corruption even when they never enabled that feature. I couldn’t really find the start of the thread in the archives, so this one kind of jumps into the middle of the thread at a relevant-looking point: https://lists.freebsd.org/archives/freebsd-current/2023-April/003446.html Regards, Alban Hertroys -- There is always an exception to always.
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