Christopher Browne wrote: > Based on discussion with Jan, I have a patch for this... > > - It comes in as a stored function: addPartialLogIndices() > - If it knows that one of the tables is unused (as happens, for > instance, after the log switch does a TRUNCATE), then it'll add a > partial index for each known origin, and drop any partial indices for > "ex-origins." > - It is invoked in several places: > - After the TRUNCATE in log switching > - After MOVE SET, CREATE SET, DROP SET, FAILOVER > > That should resolve the XXID index concerns... Does it really solve _all_ issues with xxid indexing, or does it just make them very unlikely? As far as I understand things, there are actually two problems with xxid indices 1) The "less then" operator is not stable for xxids - Only because it thinks " "xxid1 < xxid1" once, that doesn't imply that it won't think that "xxid2 < xxid1" later on. 2) xxids from origins and those from subscribers don't "mix well", because they might be 2^31 transaction apart. This can lead to transaction not being replayed on subscribers - similar to how the "xid wraparound" problem can cause data to vanish.
Doesn't the first problem (theoretically) still remain? greetings, Florian Pflug _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
