Re: "PANIC: could not open critical system index 2662" - twice
Evgeny Morozov <postgresql3@realityexists.net>
From: Evgeny Morozov <postgresql3@realityexists.net>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL General <pgsql-general@postgresql.org>
Date: 2023-04-14T07:38:42Z
Lists: pgsql-general
> Hmm, I am not certain. The block was filled with zeros from your error > message, and I think such blocks don't trigger a checksum warning. OK, so data_checksums=on might not have made any difference in this case? > So if your disk replaces a valid block with zeros (filesystem check > after crash?), that could explain what you see. If by "crash" here you mean the OS crashing - we didn't have that happen. The OS is on separate disks, which have not reported any errors. When we first ran into this problem the PG data was on a ZFS RAIDZ (i.e. RAID5) volume of 3 disks, and for one of them `zpool status -v` reported read, write and checksum error count > 0, but it also said "errors: No known data errors" and the disk status remained "online" (it did not become "faulted" or "offline"). (Now we have the PG data on a ZFS mirror volume of 2 new disks, which have not reported any errors.) 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?
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