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

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

In response to

Browse pgsql-hackers by date

  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* ...