http://www.slony.info/bugzilla/show_bug.cgi?id=234

           Summary: pg_dump + restore of a slony node leaves the node
                    corrupt
           Product: Slony-I
           Version: devel
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: stored procedures
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: ssinger at ca.afilias.info
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


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.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.