RE: ImmediateSharedRelationCacheInvalidate considered harmful

 -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Sunday, January 30, 2000 1:19 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: ImmediateSharedRelationCacheInvalidate considered harmful 
> 
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> I have been looking at the cache invalidation changes you committed
> >> on 10 Jan.  Most of them look fine, but I am suspicious of the routine
> >> ImmediateSharedRelationCacheInvalidate, which you added for md.c to
> >> call when it truncates or removes a relation.  I believe that this
> >> routine is unnecessary, and since it makes for a very ugly linkage
> >> between md.c and the cache code, I would like to take it out again.
> 
> > The call is for abort/crash after mdunlink()/mdtruncate().
> > mdunlink()/mdtruncate() is executed immediately but
> > SI registration for all backends isn't executed until commit. 
> > Yes the call is ugly and it doesn't solve the flaw basically.
> 
> Right.  As the code currently stands, we are up the creek with no
> paddle if an abort occurs after mdunlink/mdtruncate.  The only real
> solution is to postpone these operations until after commit, which
> can only be done if we change the naming convention for relation files.
> I think we are drifting towards a consensus that that has to be done.
> 
> So the question is, does ImmediateSharedRelationCacheInvalidate add
> any useful amount of (incomplete) robustness in the meantime?
> I'm not sure --- but since it's not a step towards a real solution,
> I'm inclined to leave it out.
>

OK,I would remove the call.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp