From: | Evgeny Morozov <postgresql3(at)realityexists(dot)net> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: "PANIC: could not open critical system index 2662" - twice |
Date: | 2023-05-06 12:29:36 |
Message-ID: | 01020187f109fdd0-a5cfdb9a-6118-430f-b052-0d720f57620b-000000@eu-west-1.amazonses.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2023-05-06 13:15:04 | Re: Death postgres |
Previous Message | Marc Millas | 2023-05-06 12:25:31 | Re: Death postgres |