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

> > Unfortunately, session 3 with just SELECT * FROM foo will also wait
> > for session 1 & session 2 commit.
>
> Session 3 would wait for session 2 in any case, no?
>
> This is all irrelevant unless someone can make a convincing case that
> it's safe to release read locks early. In the words of the ancient
> sage, "I can make this program arbitrarily fast ... if it doesn't have
> to give the right answer". I have already pointed out several cases
> where releasing locks early is clearly *not* safe.

Your cursor example was busted, I did not yet see an example
that would not behave perfectly well when the lock is only held until
statement end. (We all agree that the current way of taking several short term
locks during the execution of one stmt is wrong)

You yourself gave us a perfect example where not releasing the lock
is not *safe*, since it leads to an additional deadlock situation
(unless you add code to resolve it).

> I don't think I
> need to produce more examples. The burden of proof is on the other
> side to show how it can be done safely

see above

> (and with an amount of work
> that's reasonable for 7.1, which is not too darn much at this point).

This is unfortunately true.
No idea where to put that piece of code, but didn't you add statement level
cleanup somwhere to avoid keeping unnecessary memory until end of tx ?
Wouldn't that be the place to release those shared locks ?

Andreas