From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: AW: AW: Issue NOTICE for attempt to raise lock leve l? |
Date: | 2000-11-07 21:12:46 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3155@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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?
But now it will wait longer - for the duration of session 1' transaction.
> 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).
Agreed - no other way now.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-11-07 21:57:45 | Re: AW: v7.0.3 *pre-release* ... |
Previous Message | Tom Lane | 2000-11-07 21:02:19 | Re: AW: AW: Issue NOTICE for attempt to raise lock leve l? |