On 28.10.2021 4:36, Peter Geoghegan wrote:
> On Wed, Oct 27, 2021 at 12:00 AM Kamigishi Rei <iijima.yun@koumakan.jp> wrote:
> One more question: Did you use pg_restore with -j (jobs) to make the
> restore faster?
I am afraid I have not used pg_restore (as far as I know), unless psql
replicates its behaviour and/or calls it. My typical procedure is
`pg_dump[all] -U … -d … > file.sql`, followed by `psql -U … -d … <
file.sql`. It did not seem like psql used any kind of parallel query
execution, judging by the console output.
> Just one more request: Can I have some more pages from the same
> indexes? You have already provided me with
> "mediawiki.transcode_key_idx.block1.page". But could you now also
> provide me with blocks 2, 8, and 16 from the same index? This is a
> pretty random choice. I just want to see if they all contain corrupt
> posting list tuples, like page 1 (I suspect that they all will).
Despatched in a separate e-mail along with page 0 from "mediawiki.page"
requested in your follow-up message.
> Note that I pushed some additional hardening for posting list splits
> today. This will be in Postgres 14.1. The new code won't fix the
> problem, but it will detect problems earlier, limiting the damage.
Would you recommend applying the patch to my ‘production’ instance or
should keep it as is to see if that undetectable corruption case
(leading to weird SELECT etc. results) shows up again?
> These pages look like CREATE INDEX was run
> recently, despite all the corruption. Plus Herman (CC'd) has said that
> sometimes CREATE INDEX doesn't correct his own similar problem on
> Postgres 14.
CREATE INDEX was run during the import of the 13.3-generated dump; there
were no schema changes since. The transcode table gets updated every
time an audio file is uploaded, which happened quite a few times since
the upgrade.
--
K. R.