Re: Exposing the Xact commit order to the user

On Mon, May 24, 2010 at 12:51 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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