Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group