Hi all,
Fujii-san has sent me a report offline about REINDEX. And since 9.6,
trying to REINDEX directly an index of pg_class fails lamentably on an
assertion failure (mbsync failure if bypassing the assert):
#2 0x000055a9c5bfcc2c in ExceptionalCondition
(conditionName=0x55a9c5ca9750
"!(!ReindexIsProcessingIndex(((indexRelation)->rd_id)))",
errorType=0x55a9c5ca969f "FailedAssertion",
fileName=0x55a9c5ca9680 "indexam.c", lineNumber=204) at assert.c:54
#3 0x000055a9c5686dcd in index_insert (indexRelation=0x7f58402fe5d8,
values=0x7fff450c3270, isnull=0x7fff450c3250,
heap_t_ctid=0x55a9c7e2c05c,
heapRelation=0x7f584031eb68, checkUnique=UNIQUE_CHECK_YES,
indexInfo=0x55a9c7e30520) at indexam.c:204
#4 0x000055a9c5714a12 in CatalogIndexInsert
(indstate=0x55a9c7e30408, heapTuple=0x55a9c7e2c058) at indexing.c:140
#5 0x000055a9c5714b1d in CatalogTupleUpdate (heapRel=0x7f584031eb68,
otid=0x55a9c7e2c05c, tup=0x55a9c7e2c058) at indexing.c:215
#6 0x000055a9c5beda8a in RelationSetNewRelfilenode
(relation=0x7f58402fe5d8, persistence=112 'p') at relcache.c:3531
Doing a REINDEX TABLE directly on pg_class proves to work correctly,
and CONCURRENTLY is not supported for catalog tables.
Bisecting my way through it, the first commit causing the breakage is
that:
commit: 01e386a325549b7755739f31308de4be8eea110d
author: Tom Lane <tgl@sss.pgh.pa.us>
date: Wed, 23 Dec 2015 20:09:01 -0500
Avoid VACUUM FULL altogether in initdb.
Commit ed7b3b3811c5836a purported to remove initdb's use of VACUUM
FULL,
as had been agreed to in a pghackers discussion back in Dec 2014.
But it missed this one ...
The reason why this does not work is that CatalogIndexInsert() tries
to do an index_insert directly on the index worked on. And the reason
why this works at table level is that we have tweaks in
reindex_relation() to enforce the list of valid indexes in the
relation cache with RelationSetIndexList(). It seems to me that the
logic in reindex_index() is wrong from the start, and that all the
index list handling done in reindex_relation() should just be in
reindex_index() so as REINDEX INDEX gets the right call.
Thoughts?
--
Michael