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