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
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 |