Re: WIP patch for parallel pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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:41:53
Message-ID: 11860.1291344113@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 12/02/2010 09:09 PM, Tom Lane wrote:
>> 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.

[ thinks for a bit... ] Actually it might be good enough if a child
simply takes the lock it needs in nowait mode, and reports failure on
error. We know the parent already has that lock, so the only way that
the child's request can fail is if something conflicting with
AccessShareLock is queued up behind the parent's lock. So failure to
get the child lock immediately proves that the deadlock case applies.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-03 02:54:01 Re: should we set hint bits without dirtying the page?
Previous Message Tom Lane 2010-12-03 02:33:58 Re: WIP patch for parallel pg_dump