Re: "PANIC: could not open critical system index 2662" - twice

Evgeny Morozov <postgresql3@realityexists.net>

From: Evgeny Morozov <postgresql3@realityexists.net>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: PostgreSQL General <pgsql-general@postgresql.org>
Date: 2023-05-06T12:29:36Z
Lists: pgsql-general
On 6/05/2023 12:34 pm, Thomas Munro wrote:
> So it does indeed look like something unknown has replaced 32KB of
> data with 32KB of zeroes underneath us.  Are there more non-empty
> files that are all-zeroes?  Something like this might find them:
>
> for F in base/1414389/*
> do
>   if [ -s $F ] && ! xxd -p $F | grep -qEv '^(00)*$' > /dev/null
>   then
>     echo $F
>   fi
> done

Yes, a total of 309 files are all-zeroes (and 52 files are not).

I also checked the other DB that reports the same "unexpected zero page
at block 0" error, "test_behavior_638186280406544656" (OID 1414967) -
similar story there. I uploaded the lists of zeroed and non-zeroed files
and the ls -la output for both as
https://objective.realityexists.net/temp/pgstuff3.zip

I then searched recursively such all-zeroes files in $PGDATA/base and
did not find any outside of those two directories (base/1414389 and
base/1414967). None in $PGDATA/global, either.





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.