Hi All,

I have a slony cluster running on slony 2.1.0 (Have tested this 
situation on 2.1.3 also). This cluster is replicating a drupal database, 
which preforms truncates on some of the cache tables periodically. When 
the truncates execute, they fire the log_truncate trigger in slony, 
which immediatly errors due to no select permissions on the sl_table 
relation in the slony cluster.

In normal events (inserts, updates, deletes), the user doesn't need any 
permissions granted in the slony schema in order for the event trigger 
to log the event into sl_log_1, etc.

So is this a design decision, making truncates on slony tables only be 
able to be executed by superusers in the database?

I've got it working in a testing environment by granting the following:
grant select on _slony.sl_table to user;
grant insert on _slony.sl_log_status to user;
grant insert on _slony.sl_log_1 to user;
grant insert on _slony.sl_log_2 to user;
grant usage on _slony.sl_action_seq to user;

However I don't like the idea of either A. granting these permissions to 
slony tables or B. making my drupal user a 'superuser' to get around it. 
Are those my only two options here to allow truncates to work?

Thanks,
- Brian F