Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Dead(HEAP_XMAX_COMMITTED || HEAP_XMIN_INVALID) tuples never
> revive. Live (not dead) tuples never die in Share Lock mode.
Hmm ... so you're relying on the ShareLock to ensure that the state of
the tuple can't change between when heap_fetch checks it an
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> What I mean is to implement a new function
> HeapTupleSatisfiesAny() as
> bool
> HeapTupleSatisfiesAny(HeapTupleHeader tuple)
> {
> HeapTupleSatisfiesNow(tuple);
> return true;
> }
Oh, I see: so that HeapTupleSatisfies would update the hint
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> As for HeapTupleSatisfies() there seems to be another choise to
> let HeapTupleSatisfiesAny() be equivalent to HeapTupleSatisfiesNow()
> other than always returning true.
Wouldn't that break the other uses of SnapshotAny? I'm not sure
it's what nbtre
Okay, on to the next concern. I've been thinking some more about the
restrictions needed to make the world safe for concurrent VACUUM.
I previously said:
> 5. To physically remove a tuple or compact free space on a page, one
> must hold a pin and an exclusive lock, *and* observe while holding th
> On further thought, btbuild is not that badly broken at the moment,
> because CREATE INDEX acquires ShareLock on the relation, so
> there can be no concurrent writers at the page level. Still, it
> seems like it'd be a good idea to do "LockBuffer(buffer,
BUFFER_LOCK_SHARE)"
> here, and probably
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe that nbtree.c's btbuild() code is currently in violation of
>> these rules, because it calls HeapTupleSatisfiesNow() while holding a
>> pin but no lock on the containing buffer.
> OK, we had better avoid using heapam routine
