Troy Wolf: >>Now onto my issue at hand: Twice now, we've seen a pattern that looks like >>Slony is waiting on a large index creation to complete, and then an >>application gets stuck waiting behind Slony's locks.
Andrew Sullivan: >I'm not dismissing your description, but output from pg_locks would be >helpful here. Without a specific case, it's hard to say much more. I did query pg_locks at the time as well as pg_stat_activity. I know now to save that output for discussion purposes here. If anyone knows how, with postgres, to see not only the locks but exactly WHO is blocking who, please share. With pg_locks, and based on the time of the processes, I can make an educated guess. pg_locks showed 2 exclusive locks held by a nightly batch process and slony waiting for a lock and another application process waiting on a lock. This process does some data copying into some large history tables and rebuilds some indexes. These tables are not part of any replication set nor do they have any relationships to other tables. One of the locks was for an index being created. Slony showed waiting on a lock, and had been for about an hour. The moment we killed the index creation postgres process, Slony did it's thing. It was definitely waiting on that lock. I guess what I was looking for from this group was a confirmation of "Yes. Certain Slony tasks require locking ALL tables in the database--not just the replication set". Or "No, that is not possible. You need to figure out what really happened." _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
