From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
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:02:19 |
Message-ID: | 17142.973630939@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2000-11-07 21:12:46 | RE: AW: AW: Issue NOTICE for attempt to raise lock leve l? |
Previous Message | The Hermit Hacker | 2000-11-07 20:56:15 | Re: AW: v7.0.3 *pre-release* ... |