?hel kenal p?eval, E, 2006-01-16 kell 01:55, kirjutas Hannu Krosing:
> I may be barking at the wrong tree, but it seems that after one adds an
> index on sl_log_1 which actually uses index on log_xid (using xxid_ops)
> part of the index, bad things start to happen after xid grows to more
> than 2G (or maybe just 1G).
> 
> By bad things I mean both primary key conflicts and some rows not
> copied.
> 
> It may have to do with incompatibility of xxid_ops and btree indexing as
> discussed in
>     
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg00195.php
> 
> and followups.
> 
> Quote:
>   "If they do actually make btree indexes on XIDs then they
> are probably broken.
> 
> XID comparison works OK as long as you make sure that all the XIDs
> extant in the system at any one time are within +/- 2 billion of each
> other, and so transitivity does hold within that subset.  The problem
> with a btree is that upper-level tree nodes are likely to contain page
> boundary keys copied from data that vanished some time ago from the
> underlying table."
> 
> Does anybody have similar experiences, or am I doing something else
> wrong ?

To give you more context - brokage started to manifest itself more
often, after I started to replicate between geographically different
sites through 1 node so that site1:node1 to site1:nodeN replicate to
site1:replicationNode and nodes on other sites get it from there. What
this seems to cause, is that the xxid index has several sets of
different values because node1 to nodeN have different transaction
rates, and thereby I can't fix the indexes even by regular reindexing.

-------------
Hannu