Dear all -- I've discovered a problem using pg_reorg 1.1.7 with Slony versions 2.0 and/or 2.1.
If you run a reorg on a table that is part of a slony slave set while there is write activity on the master node, pg_reorg will silently drop changes committed by slony to the slave node during the reorganization. The problem is that the z_reorg_trigger doesn't fire on the changes that slony commits to the slave table, because slony has a session_replication_role on the slave of REPLICA. To get around this, after the z_reorg_trigger is created on a table, you have to run the command ALTER TABLE [table_name] ENABLE ALWAYS TRIGGER z_reorg_trigger. Then the log table will capture changes pushed by Slony (or other trigger-based replication programs) during the time of reorganizing the table. This is a subtle problem, because pg_reorg works fine with reorganizing tables on the _master_ node of a slony set, but it will drop changes on the slave nodes silently. If I have time, I'll try to write at least a rough patch for pg_reorg to fix this, but I'm hoping that both the pg_reorg and slony community can be aware of this problem. Until it's fixed, best practice would be to stop slony while reorganizing tables on a slave node. Best, Norman Yamada (Cross-posted to [email protected]) _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
