Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Manuel Rigger <rigger.manuel@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-07-23T04:28:38Z
Lists: pgsql-bugs
Attachments
- reindex-conc-predicates-v2.patch (text/x-diff) patch v2
On Mon, Jul 22, 2019 at 05:41:26PM -0400, Tom Lane wrote: > I think the correct fix is to nuke the code in REINDEX CONCURRENTLY that > thinks it should use any of this infrastructure to fetch the existing > index properties, and just have it read the catalog directly instead. Okay. Sharing a maximum the build of IndexInfo done as part of DefineIndex is something that we should do then. Attached is a patch that I have been working on, introducing a new makeIndexInfo() in makefuncs.c. Still as IndexInfo is not a parse node but an exec node, I am including execnodes.h in makefuncs.h for now (perhaps somebody has a better idea?). This fills the index information of the new entry directly from the catalog of the old entry for expressions and predicates. I have let BuildIndexInfo out of that as ii_ReadyForInserts can change for system catalogs during bootstrap. I have also reworked the test case to just use pg_get_indexdef() which is enough to show the original bug as after the initial REINDEX CONCURRENTLY the collation part goes missing when testing on HEAD. Predicates need to properly be formatted with an implicit-AND format by the way. Thoughts? -- Michael
Commits
-
Fix handling of expressions and predicates in REINDEX CONCURRENTLY
- 28bbf7a81b3a 12.0 landed
- 7cce159349cc 13.0 landed