AW: AW: AW: Issue NOTICE for attempt to raise lock leve l?

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

Yes, that needs to be fixed.

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

I think that this is a substantial modification that bears all sorts of application
side riscs. I absolutely do not think that you do not take chances when keeping
the lock. If you think it is too close to beta, then the least risk is to release the lock
after each statement, because that is a lot more like current behavior.

Andreas