RE: [HACKERS] couldn't rollback cache ?

> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> I think this is OK.  The sending backend does not send the SI message
> >> in the first place until it has committed.  Other backends can read
> 
> > Doesn't the sending backend send the SI message when Command-
> > CounterIncrement() is executed ?
> > AtCommit_Cache() is called not only from CommitTransaction() but
> > also from CommandCounterIncrement().
> 
> Oooh, you are right.  I think that is a bug.  We should postpone
> sending SI messages until commit.  Also, if I recall correctly,
> CommandCounterIncrement() still gets called after we have decided to
> abort the current transaction (while we are eating commands looking for
> END or ABORT).  It shouldn't do anything to the pending-SI list then
> either.
> 
> > AtCommit_Cache() in CommandCounterIncrement() eats local
> > invalidation messages and register SI information (this seems too
> > early for other backends though it's not so harmful). Then AtAtart_
> > Cache() eats the SI information and invalidates related syscache
> > and relcache for the backend(this seems right). At this point,invali-
> > dation info for the backend vanishes. Isn't it right ?
> 
> I think it is OK for AtStart_Cache to read *incoming* SI messages,
> if those relate to transactions that other backends have committed.
> But we should sit on our own list of pending outgoing messages until
> we know we are committing (or aborting).
>

What about delet(updat)ing backend itself ?
Shouldn't the backend invalidate delet(updat)ing old tuples ?
> >> I wonder whether it wouldn't be cleaner to identify the target tuples
> >> by OID instead of ItemPointer.  That way would work for both new and
> >> update tuples...
>

[snip]
> One thing we need to think about here: as it stands, the syscache will
> only store a single copy of any particular tuple (maybe I should say
> "of a particular OID").  But there might be several copies of that tuple
> with different t_min/t_max in the database.  With your change to check
> time qual, as soon as we realize that the copy we have no longer
> SatisfiesNow(), we'll go look for a new copy.  And we'll go look
> for a new copy after receiving a SI message indicating someone else has
> committed an update.  The question is, are there any *other* times where
> we need to look for a new copy?  I think we are OK if we change SI
> message sending to only send after commit, but I'm not sure about it.
>

What kind of tuples are read into system catalog cache ?
And what should we do to invalidate the tuples just in time ?
As far as I see,

1. HEAP_XMIN_INVALID   i.e the tuple wasn't inserted    No backend regards this tuple as valid. 

2. HEAP_XMIN_??????? && HEAP_XMAX_INVALID   i.e the tuple is being inserted now.    Only inserting backend regards this
tupleas valid.   Time qualification check which my patch does would    work in this case.   Otherwise SI message should
besent to the backend    when insertion is rollbacked.
 

3. HEAP_XMIN_??????? && HEAP_XMAX_???????   i.e the tuple is being deleted after insertion in a transaction   now.
Nobackend regards this tuple as valid.
 

4. HEAP_XMIN_COMMITTED && HEAP_XMAX_INVALID   i.e the tuple is inserted,not deleted and not being deleted.
HeapTupleSatisifies..()doesn't take effect.   SI message should be sent to all backends immediately   after the tuple
wasdeleted.   SI message should be sent to a backend immediately after   the backend marked the tuple as being
deleted.

5. HEAP_XMIN_COMMITTED && HEAP_XMAX_???????   i.e the tuple is being deleted now.    Deleting backend doesn't regard
thistuple as valid.   If SI messages are postponed to send for other backends   until commit,the tuple is invalidated
correctly.  Otherwise a check as my patch does would be necessary.
 

6. HEAP_XMAX_COMMITTED   i.e the tuple is deleted   SnapshotNow never regard this tuple as valid.

Regards.
Hiroshi Inoue
Inoue@tpf.co.jp