Horton

Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-30T04:44:26Z
Lists: pgsql-hackers 
Hi,

On April 29, 2019 9:37:33 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> I've pushed the master bits, and the other branches are running
>> check-world right now and I'll push soon unless something breaks
>(it's a
>> bit annoying that <= 9.6 can't run check-world in parallel...).
>
>Seems like putting reindexes of pg_class into a test script that runs
>in parallel with other DDL wasn't a hot idea.

Saw that. Will try to reproduce (and if necessary either run separately or revert). But isn't that somewhat broken? They're not run in a transaction, so the locking shouldn't be deadlock prone.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Commits

  1. Remove reindex_catalog test from test schedules.

  2. Remove RelationSetIndexList().

  3. Fix reindexing of pg_class indexes some more.

  4. Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.

  5. Fix potential assertion failure when reindexing a pg_class index.

  6. Fix several recently introduced issues around handling new relation forks.

  7. Avoid VACUUM FULL altogether in initdb.

  8. Introduce replication progress tracking infrastructure.

  9. initdb: remove unnecessary VACUUM FULL