If you have a slony node with transaction ids in the range of say 26005477 Then pg_dump the database Then create a new postgresql cluster (with initdb). Then restore the dumped database to that new cluster. The transaction ids assigned to new SYNC events or new rows in sl_log will be reset, ie in the range 1214. This is smaller than 26005477 even though it happened after. At a minimum rows in sl_log_1 won't be cleaned up until the current snapshot ids reach 26005477 this will prevent log switching from happening. It is also possible that data might be applied in the wrong order or not at all, but that part hasn't yet been verified. It would be good if REPAIR CONFIG could correct this situation. If not the slon sync thread should at least be able to detect the situation and log an error.
If you try to use pg_upgrade with slony you will hit a somewhat similar problem in that pg_upgrade does not bring over the transaction id epoch so the 64 bit transaction id numbers that slony gets after the pg_upgrade might seem earlier than the ones from before. pg_resetxlog has a -e option that allows you to set the transaction id epoch. This *might* solve the problem (when using pg_upgrade).