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

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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