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 ?

I can see two "easy" ways around it: 

1) always migrate db to a freshly initdb'd database before 1G
transactions

or

2) move to 64bit xids and forget our current hacery around xids and
their wraparounds

third way is to somehow keep track ow wraparounds inside slony and cast
wraparound_count*4G + xid to long int and use this as xxid. this seems
doable, but somewhat a pita. 

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