On May 25, 2010, at 3:21 , Tom Lane wrote: > Florian Pflug <f...@phlo.org> writes: >> The subtle point here is whether you consider the view from the "outside" >> (in the sense of what a read-only transaction started at an arbitrary time >> can or cannot observe), or from the "inside" (what updating transactions can >> observe and might base their updates on). > >> The former case is completely determined by the commit ordering of the >> transactions, while the latter is not - otherwise serializability 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 other transaction commits either before that time or after that time. An observer started between two transactions sees the first's changes but not the second's. One replace observing read committed transactions by a series of smaller repeatable read 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. replication that is adequate, since you'd not replay the original commands but rather the effects they had in terms of physical tuple updates. On replay, the effects of a transaction to therefor not depend on the state the transaction sees. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
