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
signature.asc
Description: PGP signature
