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