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 reorg_general at pgfoundry.org)