Re: [HACKERS] Issue NOTICE for attempt to raise lock level?

[Hiroshi Inoue]

Tom Lane wrote: > "Hiroshi Inoue" <[EMAIL PROTECTED]> 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