> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, September 17, 1999 10:58 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] couldn't rollback cache ?
>
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > But as far as I see,neither relation cache nor system catalog cache
> > aren't be rollbacked correctly.
> > I added time_qualification_check to SearchSysCache() on trial
> > (see the patch at the end of this posting).
>
> Hmm. This must be a bug of very long standing; surprising it hasn't
> been noticed before. I think you are probably right, because a little
> glimpsing shows that SearchSysCache() is the *only* place in the whole
> system where HeapKeyTest() is called directly --- everyone else goes
> through HeapTupleSatisfies() which adds a timequal check of one sort or
> another. I don't know the timequal stuff at all, but it seems likely
> that we want one here. (Vadim, is this fix right?)
>
> > After this change,
> > abort;
> > ABORT
> > select * from t1;
> > ERROR: Relation t1 does not have attribute dt1
>
> > Seems relation cache is not invalidated yet.
> > I also tried to add time_qualification_check to RelationId(Name)-
> > CacheGetRelation(). But unfortunately,Relation doesn't have
> > such a information.
>
> I think the real bug here is in inval.c: see
> InvalidationMessageCacheInvalidate, which scans pending SI messages
> at abort time. If we had committed, we'd have sent an SI message
> telling other backends to refresh their relcache entries for t1;
> so there is an entry for t1 in the pending-SI-message list. We can
> use that entry to tell us to invalidate our own relcache entry instead.
> It looks like this is done correctly for tuple SI messages but not for
I think it's not done correctly for tuple SI messages either.
I didn't use current cache invalidation mechanism when I made the
patch for SearchSysCache() because of the following 2 reasons.
1. SI messages are eaten by CommandCounterIncrement(). So they may vanish before transaction end/aborts.
2. The tuples which should be invalidated in case of abort are different from ones in case of commit. In case of
commit,deletingold tuples should be invalidated for all backends. In case of abort,insert(updat)ing new tuples
shouldbe invalidated for the insert(updat)ing backend. Currently heap_insert() calls RelationInvalidateHeapTuple()
fora inserting new tuple but heap_replace() doesn't call RelationInvalid- ateHeapTuple() for a updating new tuple.
Idon't understand which is right.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp