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

[Hiroshi Inoue]

> -----Original Message----- > From: Tom Lane > Sent: Wednesday, November 08, 2000 1:26 AM > To: [EMAIL PROTECTED] > Subject: [HACKERS] Issue NOTICE for attempt to raise lock level? > > > 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 ? Or from a rd_refcnt leak,of cource. I'm thinking that RelationCacheInvalidate() should ignore relations which are while in use. IMHO allocate_after_lock sequence is needed for heap_open(r). > The > main trick here is to make sure that the first lock grabbed is adequate > --- for example, it won't do to grab AccessShareLock and then have to > raise that to AccessExclusiveLock, because there will be a deadlock if > two backends do this concurrently. > I object to you if it also includes parse_rewrite_plan stage. If there's a long transation it would also hold a AccessShareLock on system tables for a long time. Then vacuum for system tables would be blocked. Other transactions would be blocked...... Regards. Hiroshi Inoue