Re: WIP patch for parallel pg_dump

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP patch for parallel pg_dump
Date: 2010-12-03 02:24:47
Message-ID: 4CF854EF.3080100@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/02/2010 09:09 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> On 12/02/2010 05:32 PM, Tom Lane wrote:
>>> (I'm not actually convinced that snapshot cloning is the only problem
>>> here; locking could be an issue too, if there are concurrent processes
>>> trying to take locks that will conflict with pg_dump's. But the
>>> snapshot issue is definitely a showstopper.)
>> Why is that more an issue with parallel pg_dump?
> The scenario that bothers me is
>
> 1. pg_dump parent process AccessShareLocks everything to be dumped.
>
> 2. somebody else tries to acquire AccessExclusiveLock on table foo.
> hmm.
> 3. pg_dump child process is told to dump foo, tries to acquire
> AccessShareLock.
>
> Now, process 3 is blocked behind process 2 is blocked behind process 1
> which is waiting for 3 to complete. Can you say "undetectable deadlock"?
>
>

Hmm. Yeah. Maybe we could get around it if we prefork the workers and
they all acquire locks on everything to be dumped up front in nowait
mode, right after the parent, and if they can't the whole dump fails. Or
something along those lines.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-03 02:33:58 Re: WIP patch for parallel pg_dump
Previous Message Tom Lane 2010-12-03 02:09:59 Re: WIP patch for parallel pg_dump