Noah Misch <noah@leadboat.com> writes:
> On Fri, Apr 15, 2011 at 03:01:04PM -0400, Tom Lane wrote:
>> What is happening is that the preceding "reindex table pg_index" set the
>> indcheckxmin flag for pg_index's indexes. The new table built by vacuum
>> full contains no HOT chains at all, let alone broken ones, so at the end
>> of reindex_index we decide we ought to clear the indcheckxmin flag.
>> But we are not done swapping the old and new indexes, so the uniqueness
>> check doesn't work right --- I believe it's looking into the old index
>> and finding a TID that means something totally different in the new
>> table.
> For that matter, I believe it's also attempting to insert into the old index.
I wondered about that, but it seemed to me that if that happened, it
ought to have much more visible symptoms --- ie, the committed row would
not be findable through the new index. The typical case according to my
testing was that the unique check wouldn't fail, so we should have been
hearing reports of pg_index searches failing post-VACUUM, and we
weren't. I did not expend the time to trace it down in detail, though,
once I'd gotten the general picture of what was happening.
> I think we're safe _consulting_ the system catalogs, since systable_beginscan
> notes that case and does not use obsolete indexes. Any other system catalog
> _updates_ are potentially risky, though. Perhaps index_insert() and friends
> should assert that the index is not pending rebuild?
[ squint... ] Won't that result in the rebuild failing outright? We
can't remove an index from the pending list till after it's rebuilt,
for obvious reasons.
regards, tom lane