Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6
От | Tom Lane |
---|---|
Тема | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |
Дата | |
Msg-id | 4870.1556811688@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: REINDEX INDEX results in a crash for an index of pg_class since9.6 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > ISTM that if we go down this path, we should split (not now, but either > still in v12, or *early* in v13), the sets of indexes that are intended > to a) not being used for catalog queries b) may be skipped for index > insertions. It seems pretty likely that somebody will otherwise soon > introduce an heap_update() somewhere into the index build process, and > it'll work just fine in testing due to HOT. Given the assertions you added in CatalogIndexInsert, I'm not sure why that's a big hazard? > I kinda wonder if there's not a third approach hiding somewhere here. We > could just stop updating pg_class in RelationSetNewRelfilenode() in > pg_class, when it's an index on pg_class. Hmm ... are all those indexes mapped? I guess so. But don't we need to worry about resetting relfrozenxid? regards, tom lane
В списке pgsql-hackers по дате отправления: