Tom Lane wrote:
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> I am working on eliminating the "relation NNN modified while in use"
> >> misfeature by instead grabbing a lock on each relation at first use
> >> in a statement, and holding that lock till end of transaction.
>
> > Isn't "relation NNN modified while in use" itself coming from heap_
> > open(r) 's LockRelation_after_allocate sequence ?
>
> Right. I intend to eliminate that test entirely, and simply let the
> relcache update happen. With appropriate start-to-end locking, it
> shouldn't be possible for a schema update to sneak in at an unsafe
> point.
>
> The only reason that there is a "modified while in use" test at all
> is that I put it in awhile back as a stopgap solution until we did
> a better job with the end-to-end locking problem. The reports coming
> back on 7.0.* make it clear that the stopgap answer isn't good enough,
> so I want to fix it right for 7.1.
>
> > I'm thinking that RelationCacheInvalidate() should ignore relations
> > which are while in use.
>
> Won't work unless you somehow store an "update needed" flag to make the
> update happen later --- you can't just discard a shared-inval
> notification.
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 ? 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().
Comments ?
Regards.
Hiroshi Inoue