On Thursday, October 11, 2012 04:49:20 AM Andres Freund wrote: > On Thursday, October 11, 2012 04:31:21 AM Tom Lane wrote: > > Greg Stark <st...@mit.edu> writes: > > > On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > >> 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? > > > > > > > > > > > > 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. > > > > > > > > I would believe that argument if the "apply" operations were at a > > similar logical level to our current WAL records, namely drop these bits > > into that spot. Unfortunately, they're not. I think this argument > > falls to the ground entirely as soon as you think about DDL being > > applied by transactions A,B,C and then needing to express what > > concurrent transactions X,Y,Z did in "source" terms. Even something as > > simple as a few column renames could break it, > > Not sure what youre getting at here? Are you talking about the problems at > the source side or the target side? > > During decoding such problems should be handled already Btw, the introductionary email upthread shows a trivial example. As submitted the code cannot handle intermingled DDL/DML transactions, but I fixed that now.
There are some problems with CLUSTER/VACUUM FULL on system catalogs, but thats going to be separate thread... Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
