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 по дате отправления: