On 10/11/2012 04:31 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, let alone anything as
esoteric as changing the meaning of datatype literals.
This is the whole reason of moving the reassembly to the source
side and having the possibility to use old snapshots to get the
catalog information.
Also, the locks that protect you from effects of field name changes
by DDL concurrent transactions protect also the logical reassembly
if done in the commit order.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
