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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6
Date: 2019-04-24 00:13:14
Message-ID: 20190424001314.GD1878@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 23, 2019 at 07:54:52PM -0400, Tom Lane wrote:
> That seems like pretty much of a hack :-(, in particular I'm not
> convinced that we'd not end up with a missing index entry afterwards.
> Maybe it's the only way, but I think first we need to trace down
> exactly why this broke. I remember we had some special-case code
> for reindexing pg_class, maybe something broke that?

Yes, reindex_relation() has some infra to enforce the list of indexes
in the cache for pg_class which has been introduced by a56a016 as far
as it goes.

> It also seems quite odd that it doesn't fail every time; surely it's
> not conditional whether we'll try to insert a new pg_class tuple or not?
> We need to understand that, too. Maybe the old code never really
> worked in all cases? It seems clear that the commit you bisected to
> just allowed a pre-existing misbehavior to become exposed (more easily).
>
> No time to look closer right now.

Yeah, there is a fishy smell underneath which comes from 9.6. When
testing with 9.5 or older a database creation does not create any
crash on a subsequent reindex. Not sure I'll have the time to look at
that more today, perhaps tomorrow depending on the odds.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-04-24 00:25:41 Re: pg_dump is broken for partition tablespaces
Previous Message Tom Lane 2019-04-24 00:03:37 Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6