RE: [HACKERS] couldn't rollback cache ?

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: Wednesday, September 22, 1999 7:12 PM
> To: Tom Lane
> Cc: pgsql-hackers
> Subject: RE: [HACKERS] couldn't rollback cache ? 
> 

I thought about the way which neither calls HeapTupleSatis-
fies() in SearchSysCache() nor invalidates syscache entry
by OID.

In this case,we would need the information as follows.

1. To_be_rollbacked info for the backend   A list of being inserted system tuples.   This list is held till end of
transaction.  In case of commit,this list is ignored and discarded.   In case of rollback,tuples inserted after the
specified  savepoint are rollbacked and discarded. Syscache   and relcache entries for the backend which correspond
tothe tuples are invalidated.
 

2, To_be_invalidated info for the backend   A list of being deleted system tuples.   This list is discarded at every
command.  In case of rollback this list is ignored.   Otherwise,syscache and relcache entries for the backend   which
correspondto the tuples in this list are invalidated   before execution of each command. 
 

3. To_be_invalidated info for other backends   A list of being deleted system tuples.   This list is held till end of
transaction.  In case of commit,this list is sent to other backends and   discarded.   In case of rollback,tuples
deletedafter the specified savepoint   are discarded.
 

4. Immediate registrarion of to_be_invalidated relcache for all backends   Currently SI messages aren't sent in case of
elog(ERROR/FATAL).  Seems the following commands have to register relcache invali-   dation for all backends just when
wecall smgrunlink()/smgrtruncate(). 
 
   DROP TABLE/INDEX   TRUNCATE TABLE(implemented by Mike Mascari)   VACUUM

Comments ?

Hiroshi Inoue
Inoue@tpf.co.jp