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
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 |