Tom Lane wrote:
> I said:
> > This class of bugs has been there since the beginning of Postgres,
> > so I do not feel that we need to panic about it. Let's take the
> > time to design and implement a proper solution, rather than expending
> > effort on a stopgap solution that'll have to be undone later.
>
> I've reviewed the earlier threads on SearchSysCache and done some more
> thinking. Here is a concrete proposal for doing it right:
>
> 1. Add a reference-count field and an already-dead boolean to each
[snip]
I agree with your proposal.
>
> 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).
RowExclusiveLock doesn't conflcit each other.
There seems to be few places where above locks for
system relations are appropriate.
Regards.
Hiroshi Inoue
