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. As we reconstruct a
Snapshot that lets catalog access look like it did back when the tuple was
thrown into was we have the exact column names, data types and everything. The
locking used when making the original changes prevents the data types, column
names to be changed mid-transaction.
If youre talking about the receiving/apply side: Sure, if you do careless DDL
and you don't replicate DDL (not included here, separate project), youre going
to have problems. I don't think there is much we can do about that.
> let alone anything as esoteric as changing the meaning of datatype literals.
Hm. You mean like changing the input format of a datatype? Yes, sure, that
will cause havoc.
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
