Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> What I mean is to change heap_open(r) like
> LockRelationId(Name) -> shared-inval-handling ->
> allocate the relation descriptor and increment rd_refcnt
> This would ensure that relations with rd_refcnt > 0
> acquire some lock. Could any shared-inval-noti
> fication arrive for such relations under the me-
> chanism ?
Yes, because the system doesn't make any attempt to ensure that relcache
entries are held open throughout a statement or transaction. (If they
were, we largely wouldn't have a problem.) So we can't use relcache
refcount going from 0 to 1 as the sole criterion for when to acquire
a lock.
I did look at using the relcache to control holding locks throughout
statements, but it seems that it doesn't have enough information
to grab the right kind of lock. For example, I had to modify the
parser to ensure that the right kind of lock is grabbed on the
initial relcache access, depending on whether the table involved is
accessed for plain SELECT, SELECT FOR UPDATE, or INSERT/UPDATE/DELETE.
I still have to make a similar change in the rewriter for table
references that are added to a query by rewrite. The code that is
doing this stuff knows full well that it is making the first reference
to a table, and so the relcache doesn't really have anything to
contribute.
> However 'reset system cache' message
> could arrive at any time. I've examined the error
> 'recursive use of cache' for some time. It seems
> very difficult to avoid the error if we reconstruct
> relation descriptors whose rd_refcnt > 0 in
> RelationCacheInvalidate().
I haven't had time to look at that yet, but one possible answer is just
to disable the 'recursive use of cache' test. It's only a debugging
sanity-check anyway, not essential functionality.
regards, tom lane