Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.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