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>, "Peter J. Holzer" <hjp-pgsql@hjp.at>
Date: 2023-04-11T16:44:54Z
Lists: pgsql-general
> No idea about the former, but bad hardware is a good enough explanation.
> As to keeping it from happening: use good hardware.

Alright, thanks, I'll just keep my fingers crossed that it doesn't
happen again then!

> Also: Use checksums. PostgreSQL offers data checksums[1]. Some
filesystems also offer checksums.

We have data_checksums=on. (It must be on by default, since I cannot
find that in our config files anywhere.) However, the docs say "Only
data pages are protected by checksums; internal data structures and
temporary files are not.", so I guess pg_class_oid_index might be an
"internal data structure"?

We also have checksum=on for the ZFS dataset on which the data is stored
(also the default - we didn't change it). ZFS did detect problems (zpool
status reported read, write and checksum errors for one of the old
disks), but it also said "errors: No known data errors". I understood
that to meant that it recovered from the errors, i.e. wrote the data
different disk blocks or read it from another disk in the pool.





Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Handle DROP DATABASE getting interrupted

  2. Remove the restriction that the relmap must be 512 bytes.