On Mon, May 24, 2010 at 12:51 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
