On 7/20/2006 9:07 PM, Florian G. Pflug wrote:

> 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.

The fact that we do log table rotating and truncating will wipe out all 
old index levels that could possibly suffer from that problem.

> 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.

As long as comparisions of xxids are limited to stay within one node ID 
(and with either the node ID being the first index column or the index 
being partial by node ID this is guaranteed), there is no such problem.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #