I’ve just been looking into some issues with locking in Postgres and the documentation as ever has been excellent.
A closer look at the queries provided suggests they don’t show table level locks. At the very least if you do a
pg_dump of your database while checking those queries you see nothing, despite there definitely being some locks going on. This query probably isn’t perfect, and is simply based on a quick practical test of running
pg_dump against a test db but it may help spot the table locks which could be blocking things.
select pid, usename, datname, current_query
from pg_catalog.pg_locks l
inner join pg_catalog.pg_stat_activity a on a.procpid = pid
where mode like '%ExclusiveLock%';
While we’ve been doing a lot of OpenERP deployment we have been discovering various ways to configure it and one turns out to be very handy for debugging. If you’ve ever debugged OpenERP using the
--debug flag and dropped into the debugger you have probably noticed the system carries on doing things while you’re sat at the debugger prompt. Often obliterating what you were looking at. This generally happens because OpenERP generally runs with multiple threads out of the box, and some of those threads do the ‘cron’ jobs, the background tasks, so even if you haven’t tried to do anything on the website, there will be activity. If you want to prevent the cron activity from making your debugging session more confusing than it needs to be add the
--max-cron-threads=0 flag when you run OpenERP.