Re: Issue NOTICE for attempt to raise lock level?

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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. And if you did that, you'd have synchronization issues
to contend with. Since we use SnapshotNow for reading catalogs, catalog
fetches may see data that is inconsistent with the current state of the
relcache. Not good. Forcing the schema update to be held off in the
first place seems the right answer.

> 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.

No, I'm going to leave locking of system catalogs as-is. This basically
means that we don't support concurrent alteration of schemas for system
tables. Seems like an OK tradeoff to me ...

regards, tom lane