RE: [HACKERS] couldn't rollback cache ?

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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(at)tpf(dot)co(dot)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,deleting old tuples should be invalidated for all
backends.
In case of abort,insert(updat)ing new tuples should be invalidated
for the insert(updat)ing backend.
Currently heap_insert() calls RelationInvalidateHeapTuple() for a
inserting new tuple but heap_replace() doesn't call RelationInvalid-
ateHeapTuple() for a updating new tuple. I don't understand which
is right.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp