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 wrong and
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
On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Greg Stark st...@enterprisedb.com writes:
On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Gregory Stark st...@enterprisedb.com 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.
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com 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
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.
Hmm ... if updates to pg_index entries were
Tom Lane t...@sss.pgh.pa.us writes:
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.
Hmm
