On Sun, Jan 31, 2010 at 4:02 PM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: >> I've found this discussion in -HACKERS: >> http://osdir.com/ml/pgsql-hackers/2009-11/msg00265.html It seems, it's >> exactly what I need to do. I might try to contribute a patch. > Well, if you're able to that'd be absolutely brilliant :-) I have already checked out the sources of PostgreSQL and started to look how to hook up the required functionality and then I found this: http://archives.postgresql.org/pgsql-hackers/2010-01/msg00916.php :) It would be really nice to have it in the next PostgreSQL release. I'll write a parallel variant of pg_dump so this functionality won't be left unused. >>>> So, is there a way to somehow stop all mutating operations? >>> Take explicit locks on the resources of interest that are permissive >>> enough >>> to be shared with other read transactions, but not to permit writes. >> I thought about it, but it's too deadlock-prone. I need to lock the >> whole database, and if I do this table-by-table then I'll almost >> certainly generate a deadlock. > Not if you specify, and stick to, a strict lock acquisition order and never > try to upgrade a lock you already hold. That's not possible, I'm afraid. My code is essentially a 'parallel pg_dump' and it needs to dump the whole database. So it's just not possible to stick to the same locking order. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
