Re: [HACKERS] couldn't rollback cache ?

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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).

>> 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...

> This may be a better way because the cache entry which should be
> invalidated are invalidated.
> However,we may invalidate still valid cache entry by OID(it's not so
> harmful). Even time qualification is useless in this case.

Doesn't bother me --- we'll just re-read it. We'd have to do some work
in that case anyway to verify whether we have the correct copy of the
tuple.

>> OTOH, your change to add a time qual check
>> to SearchSysCache would fix that, wouldn't it?

> Probably. Because time qualification is applied for uncommitted tuples.

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.

regards, tom lane