"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.
Just my $0.02 worth; if you think it's better to leave it in until
we have a complete solution, I will go along.
> 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.
Hmm, haven't looked at that...
regards, tom lane