On Thu, Oct 11, 2012 at 03:16:39AM +0100, Greg Stark wrote: > On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I think I've mentioned it before, but in the interest of not being > >> seen to critique the bikeshed only after it's been painted: this > >> design gives up something very important that exists in our current > >> built-in replication solution, namely pipelining. > > > > Isn't there an even more serious problem, namely that this assumes > > *all* transactions are serializable? What happens when they aren't? > > Or even just that the effective commit order is not XID order? > > Firstly, I haven't read the code but I'm confident it doesn't make the > elementary error of assuming commit order == xid order. I assume it's > applying the reassembled transactions in commit order. > > I don't think it assumes the transactions are serializable because > it's only concerned with writes, not reads. So the transaction it's > replaying may or may not have been able to view the data written by > other transactions that commited earlier but it doesn't matter when > trying to reproduce the effects using constants. The data written by > this transaction is either written or not when the commit happens and > it's all written or not at that time. Even in non-serializable mode > updates take row locks and nobody can see the data or modify it until > the transaction commits.
How does Slony write its changes without causing serialization replay conflicts? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
