Gregory Stark <st...@enterprisedb.com> writes:
>> Another thought now though. What if someone updates the pg_index entry --
>> since we never reset indcheckxmin then the new tuple will have a new xmin and
>> will suddenly become invisible again for no reason.
> Fixing this for REINDEX is fairly straightforward I think. It already updates
> the pg_index line to fix indisvalid and indisready. see:
I realized what was bothering me about that patch: it could reset
indcheckxmin too soon, ie, while there are still transactions that
shouldn't use the index.
I propose that we modify it slightly: if we are updating a pg_index
row, and indcheckxmin is set, *and the old xmin is below the GlobalXmin
horizon*, then reset indcheckxmin. Otherwise leave it set, which will
mean that we postpone the time when the index becomes usable to
everyone, but it won't risk breaking anything.
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
