RE: ImmediateSharedRelationCacheInvalidate considered harmful

-----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Sunday, January 30, 2000 1:19 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: ImmediateSharedRelationCacheInvalidate considered harmful
>
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp