Noah Misch <n...@leadboat.com> writes:
> Commit d2f60a3ab055fb61c8e1056a7c5652f1dec85e00 added an assert to indexam.c's
> RELATION_CHECKS to block use of an index while it's being rebuilt. This
> assert trips while rechecking an exclusion constraint after an ALTER TABLE
> rebuild:
> CREATE TABLE t (
> c int,
> EXCLUDE (c WITH =)
> );
> INSERT INTO t VALUES (1), (2);
> ALTER TABLE t ALTER c TYPE smallint USING 1;
Mph ... obviously not tested enough ...
> I could not come up with an actual wrong behavior arising from this usage, so
> I'll tentatively call it a false positive. reindex_index() could instead
> unconditionally clear indexInfo->ii_Exclusion* before calling index_build(),
> then pop pendingReindexedIndexes and call IndexCheckExclusion() itself.
> Popping
> pendingReindexedIndexes as we go can make the success of a reindex_relation()
> dependent on the order in which we choose to rebuild indexes, though.
> Another option is to just remove the assert as not worth preserving.
Removing the assert would be a seriously bad idea IMO. I think we could
just allow index_build to call ResetReindexProcessing() midstream (ie,
before it calls IndexCheckExclusion). This does raise the question of
whether the existing call to IndexCheckExclusion is badly placed and
we should move it to after the index is "fully" rebuilt. That would
allow us to avoid doing ResetReindexProcessing until the index is
clearly safe to use.
So in short, I'm thinking move lines 1760-1772 (in HEAD) of index.c to
the end of index_build(), then insert a ResetReindexProcessing() call in
front of them; or maybe only do ResetReindexProcessing there if we
actually do call IndexCheckExclusion.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
