On Mon, May 24, 2010 at 12:51 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas wrote:
>> I think you're confusing two subtly different things.
>
> The only thing I'm confused about is what benefit anyone expects to
> get from looking at data between commits in some way other than our
> current snapshot mechanism. Can someone explain a use case where
> what Jan is proposing is better than snapshot isolation? It doesn't
> provide any additional integrity guarantees that I can see.
It's a tool for replication solutions to use.
>> But the commit order is still the order the effects of those
>> transactions have become visible - if we inserted a new read-only
>> transaction into the stream at some arbitrary point in time, it
>> would see all the transactions which committed before it and none
>> of those that committed afterward.
>
> Isn't that what a snapshot does already?
Yes, for a particular transaction. But this is to allow transactions
to be replayed (in order) on another node.
>> your proposed fix sounds like it would be prohibitively expensive
>> for many users. But can this actually happen?
>
> How so? The transaction start/end logging, or looking at that data
> when building a snapshot?
I guess what I'm asking is - if the reconstructed transaction order
inferred by SSI doesn't match the actual commit order, can we get a
serialization anomaly on the standby by replaying transactions there
in commit order? Can you give an example and explain how your
proposal would solve it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
