REINDEX INDEX results in a crash for an index of pg_class since 9.6

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Masao Fujii <FujiiMasaomasao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: REINDEX INDEX results in a crash for an index of pg_class since 9.6
Date: 2019-04-18 01:14:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
errorType=0x55a9c5ca969f "FailedAssertion",
fileName=0x55a9c5ca9680 "indexam.c", lineNumber=204) at assert.c:54
#3 0x000055a9c5686dcd in index_insert (indexRelation=0x7f58402fe5d8,
values=0x7fff450c3270, isnull=0x7fff450c3250,
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
commit: 01e386a325549b7755739f31308de4be8eea110d
author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
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.



Browse pgsql-hackers by date

  From Date Subject
Next Message Kato, Sho 2019-04-18 02:09:52 RE: Speeding up creating UPDATE/DELETE generic plan for partitioned table into a lot
Previous Message John Naylor 2019-04-18 01:08:36 Re: jsonpath