On Sun, Jan 31, 2010 at 4:02 PM, Craig Ringer
<craig@postnewspapers.com.au> 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.
