Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>> Callers that want to be certain they have a completely-up-to-date copy
>> should acquire a suitable lock on the associated system relation before
>> calling SearchSysCache().
> I'm suspcious if it's practical.
> What is a suitable lock ?
> The lock should conflict with RowExclusiveLock at least.
> It must be one of the lock which is stronger than Row
> ExclusiveLock or ShareLock(ShareLock is neither stronger
> nor weaker than RowExclusiveLock).
I think RowExclusiveLock is sufficient. The thing that we want a
table-level lock to do is to ensure that there are no *table level*
reasons for not proceeding with the update. An obvious example is that
we don't want any VACUUM to be running on that table and perhaps moving
our tuple around.
I think you are concerned about whether there might be concurrent
updates to the particular tuple we want to update. You are right to
be concerned, but obtaining a table-level lock is a bad solution to
that because it doesn't allow for any concurrency --- if we do it
that way then we can have only one writer *per table*. Also the risks
of deadlock from obtaining locks in different orders in different parts
of the code become much higher than if we are locking individual tuples.
Most of the places where we need to update multiple system-catalog
tuples in a single command are schema updates to a single relation.
For that, I think a reasonable approach is to rely on locking the
relation being modified; we're going to want exclusive lock on that
relation anyway, and that should be enough to ensure no one else is
doing schema updates on that relation. Commands that alter just a
single system-catalog tuple, like DROP TYPE or some such, don't
really need any more interlocking than will be supplied automatically
by heap_update or heap_delete.
In short I don't think there's a big problem here.
regards, tom lane
PS: I'm working on the SearchSysCache changes I outlined, and hopefully
will be ready to commit tomorrow. One thing I've discovered already
is that there is still a use for SearchSysCacheCopy: callers who intend
to modify and update the tuple want to receive a modifiable copy, not
a cached tuple that they mustn't change.
