On Fri, Oct 2, 2009 at 3:14 AM, Andrew Sullivan <[email protected]> wrote:
On Thu, Oct 01, 2009 at 04:20:52PM +0700, [email protected] wrote:EXECUTE SCRIPT wants to lock all tables, despite me being a consenting adult who promises not to muck with tables outside of the specified SET ID set.[…]Are there other alternatives, such as a version of EXECUTE SCRIPT that has less paranoid locking behavior?In the Old Days of Slony, EXECUTE SCRIPT locked the tables in the set, not all tables. It was changed because there was no way to prevent people from inflicting self-damage. I suppose you ought to be able to re-patch the modern code with something like the old version. I recall feeling somewhat equivocal about this change, precisely because it would forestall exactly the sort of thing you are now trying to do. I seem to recall doing something similar with bare metal functions, however, so you may be able to get around this just by not using EXECUTE SCRIPT.
Thanks. I think I will be able to avoid the problem this time by moving the small highly available set master to a dedicated server which does not have a replica of the larger replication set (this was happening anyway). The services that need access during maintenance will just need to use the master only (the tables on the slaves will be locked - they need to exist in the same databases as the larger replication sets as we need to run JOINs between them). I do think that this locking behavior should be optional or even reverted - I can understand the desire to stop users shooting themselves in the foot but in this case is also removes useful functionality for little gain (users still have plenty of other ways to shoot themselves in the foot, such as truncate, drop table, executing scripts on incorrect nodes, etc.). I do foresee this biting me again in the future as I break my large replication set into smaller chunks to allow me to perform maintenance on parts of the system without the whole system needing to go down, so I'm sure I'll be revisiting and decide then if I should get Slony-I patched or rework my rollout and maintenance tools to not use slonik. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
