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: pgsql-hackers@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Date: 2019-05-06T07:01:05Z
Lists: pgsql-hackers 
On 2019-05-06 00:00:04 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On May 5, 2019 8:56:58 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> On this coast, "tonight" is running into "tomorrow" ... you planning
> >> to do that soon?
>
> > I'd planned to finish cooking and eating, and then doing it. Seems like that'd be plenty early?
>
> Sure, dinner can take priority.

And pushed.

I've not done so for 12. For one, because there's no imminent release,
and there's plenty reindexing related changes in 12. But also because I
have two vague ideas that might allow us to keep the test in the regular
schedule.

1) Is there a way that we could just use the type of logic we use for
   CREATE INDEX CONCURRENTLY to force waiting for previously started
   sessions, before doing the REINDEXing of pg_class et al?

   I think it'd work to just add a CREATE INDEX CONCURRENTLY in a
   transaction, after taking an exclusive lock on pg_class - but I
   suspect that'd be just as deadlock prone, just for different reasons?

2) Couldn't we just add a simple loop in plpgsql that checks that the
   previous session ended? A simple DO loop around SELECT pid FROM
   pg_stat_activity WHERE datname = current_database() AND pid <>
   pg_backend_pid(); doesn't sound like it'd be too complicated?  That
   wouldn't work in older releases, because we e.g. wouldn't see
   autoanalyze anywhere conveniently.

   I'm afraid there'd still be the issue that an autoanalyze could spin
   up concurrently? And we can't just prevent that by locking pg_class,
   because we'd otherwise just have the same deadlock?


I for sure thought I earlier had an idea that'd actually work. But
either I've lost it, or it didn't actually work. But perhaps somebody
else can come up with something based on the above strawman ideas?

Greetings,

Andres Freund

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