RE: 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