Re: AW: AW: Issue NOTICE for attempt to raise lock level?

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> Ok, but I thought there was some optimization for readonly statements.

Doesn't have anything to do with locking, only with avoiding disk
writes.

>> In the second place, we already grab locks that we do not release till
>> end of xact for all user-level queries. The problem is that we grab
>> them too late, ie, in the executor. I'm just planning to move up the
>> grab till first use.

> For a "select colname from tablename" we do not currently hold any lock
> until end of tx. This is the situation you described, and I am worried about.

That's a bug in itself, because the executor's read lock is grabbed by
heap_beginscan and released by heap_endscan, which means it may be
grabbed and released multiple times during a single query (think
nested-loop join). There is nothing to stop someone from, say, dropping
the entire table between scans. I intend to fix that.

I am not nearly as worried about long-running transactions that delay
admin actions as I am about admin actions that crash other transactions.
I do not believe it is safe to drop read locks intra-transaction, and
I am unwilling to take a chance on it being safe so close to 7.1 beta.
We can argue about it when 7.2 development cycle starts, if you like.

regards, tom lane