Bug 234 - pg_dump + restore of a slony node leaves the node corrupt
Summary: pg_dump + restore of a slony node leaves the node corrupt
Status: NEW
Alias: None
Product: Slony-I
Classification: Unclassified
Component: stored procedures (show other bugs)
Version: devel
Hardware: PC Linux
: low enhancement
Assignee: Slony Bugs List
Depends on:
Reported: 2011-08-18 07:44 UTC by Steve Singer
Modified: 2011-08-18 08:28 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Steve Singer 2011-08-18 07:44:39 UTC
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.
Comment 1 Steve Singer 2011-08-18 08:28:01 UTC
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).