Re: AW: Re: [SQL] possible row locking bug in 7.0.3 & 7.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)at>
Cc: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Date: 2001-03-30 15:05:40
Message-ID: 918.985964740@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)at> writes:
> It is intuitive. The bug was iirc, that you saw 2 versions of the same row
> in the second select statement (= 2 rows returned by second select).

I think we should be extremely wary of assuming that we have a clear
characterization of "what the bug is", let alone "how to fix it".
The real issue here is that SELECT has different MVCC visibility rules
from UPDATE and SELECT FOR UPDATE. I suspect that that *must* be so
in any mode that allows more concurrency than full serializable mode.
Thus, the question we are really facing is how we might alter the
visibility rules in a way that will make the results more intuitive
and/or useful while still allowing concurrency.

This will take thought, research and discussion. A quick fix is the
last thing that should be on our minds.

A first question: where did the MVCC rules come from originally, anyway?
Is there any academic research to look at?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-30 15:15:28 Re: HUGE BUG - Please fix!!!
Previous Message Thomas Lockhart 2001-03-30 15:04:25 Re: Call for platforms