RE: ImmediateSharedRelationCacheInvalidate considered harmful - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: ImmediateSharedRelationCacheInvalidate considered harmful
Date
Msg-id NDBBIJLOILGIKBGDINDFIEIECCAA.Inoue@tpf.co.jp
Whole thread Raw
In response to ImmediateSharedRelationCacheInvalidate considered harmful  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ImmediateSharedRelationCacheInvalidate considered harmful
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> Hiroshi,
>   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.
>

I'm happy you have noticed it.

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.
Transaction control of relation files' handling would solve
it basically. Though I have hesitated to add the call,after
all I added it because it may be brought to developers' notice.
I don't mind to take it out 

BTW strictly speaking,even a possibilty exists that backends
fail between RecordTransactionCommit() and AtCommit_Cache()
in CommitTransaction(). This isn't so little a problem if we want
a really strict consistency but seems very hard to solve.

Regards. 
Hiroshi Inoue
Inoue@tpf.co.jp


pgsql-hackers by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: [HACKERS] Re: Copyright
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Sure enough, SI buffer overrun is broken