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

> > Will we still have readers-dont-block-writers behaviour?
> 
> Sure.  The only thing this really affects is VACUUM and 
> schema-altering
> commands, which will now have to wait until reader 
> transactions commit.
> In other words
> 
>     Session 1            Session 2
> 
>     BEGIN;
>     SELECT * FROM foo;
> 
>                     ALTER TABLE foo ...
> 
>     ...
> 
>     COMMIT;
> 
> Session 2 will have to wait for session 1 to commit; before it didn't.

Not only, Tom -:)
Unfortunately, session 3 with just SELECT * FROM foo will also wait
for session 1 & session 2 commit.

Vadim

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 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.  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 (and with an amount of work
that's reasonable for 7.1, which is not too darn much at this point).
        regards, tom lane