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 <stark@mit.edu> writes:
> > > On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane <tgl@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
