RE: Issue NOTICE for attempt to raise lock level?

> -----Original Message-----
> From: Tom Lane
> Sent: Wednesday, November 08, 2000 1:26 AM
> To: pgsql-hackers(at)postgreSQL(dot)org
> 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