"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I am right now working on to get HOT and VACUUM FULL work
> together. I hit upon a bug which I initially thought is
> something that HOT has introduced. But I can reproduce
> it with CVS HEAD as well.
I think we broke this in 8.2: vac_update_relstats needs to ensure that
it always sends a relcache invalidation event, but as of 8.2 it's set
up to conditionally update the pg_class entry only if it wrote new
values into the tuple. If vacuum full is truncating the rel back to
the same length that it was on the previous cycle (as is always the
case in this test), then no update, hence no relcache flush, hence
clients still think their cached rd_targblock is good. I think the
code in vac_update_relstats
if (dirty)
heap_inplace_update(rd, ctup);
needs to look more like what index_update_stats does:
if (dirty)
{
heap_inplace_update(pg_class, tuple);
/* the above sends a cache inval message */
}
else
{
/* no need to change tuple, but force relcache inval anyway */
CacheInvalidateRelcacheByTuple(tuple);
}
Please check if this makes it go away for you --- I'm a bit busy
at the moment.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
