I wrote:
> We could reorganize the function slightly so that the IndexInfo is
> still available after the PG_TRY block, and then do something like
> "if (!indexInfo->ii_BrokenHotChain) reset indcheckxmin". This would
> ensure that we didn't wipe the flag if index_build had just set it.
> If I'm wr
Greg Stark writes:
> On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane wrote:
>> 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.
> That doesn't sound like the right solution. What we want
On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane wrote:
> Gregory Stark 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.
>
>
Gregory Stark 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. I
Tom Lane writes:
> Gregory Stark 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.
>
> Hmm ... if updates to pg_index entries
Gregory Stark 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.
Hmm ... if updates to pg_index entries were common then I could g
Tom Lane writes:
> Gregory Stark writes:
>> So it occurs to me that freezing xmin won't actually do what we want for
>> indexcheckxmin. Namely it'll make the index *never* be used.
>
> How do you figure that? FrozenXID is certainly in the past from any
> vantage point.
Uhm, I'm not sure what I
Gregory Stark writes:
> So it occurs to me that freezing xmin won't actually do what we want for
> indexcheckxmin. Namely it'll make the index *never* be used.
How do you figure that? FrozenXID is certainly in the past from any
vantage point.
regards, tom lane
--
Sent
In answering the recent question on -general I reread README.HOT and had a
couple thoughts:
> Practically, we prevent certain transactions from using the new index by
> setting pg_index.indcheckxmin to TRUE. Transactions are allowed to use
> such an index only after pg_index.xmin is below their
