On May 25, 2010, at 3:21 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> The subtle point here is whether you consider the view from the "outside" (in the sense of what a read-only
transactionstarted at an arbitrary time can or cannot observe), or from the "inside" (what updating transactions can
observeand might base their updates on).
>
>> The former case is completely determined by the commit ordering of the transactions, while the latter is not -
otherwiseserializability wouldn't be such a hard problem.
>
> BTW, doesn't all this logic fall in a heap as soon as you consider
> read-committed transactions?
Why would it? There's still a well defined point in time at which the transaction's effects become visible, and every
othertransaction commits either before that time or after that time. An observer started between two transactions sees
thefirst's changes but not the second's. One replace observing read committed transactions by a series of smaller
repeatableread transactions, since the observers are read-only anyway.
This of course says nothing about what state the updating transactions themselves see as the current state. For e.g.
replicationthat is adequate, since you'd not replay the original commands but rather the effects they had in terms of
physicaltuple updates. On replay, the effects of a transaction to therefor not depend on the state the transaction
sees.
best regards,
Florian Pflug
