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 03:03:33 |
Message-ID: | 4CF85E05.7050706@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/02/2010 09:41 PM, Tom Lane wrote:
> 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.
>
>
Yeah, that would be a whole lot simpler. It would avoid the deadlock,
but it would have lots more chances for failure. But it would at least
be a good place to start.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-12-03 03:15:28 | Re: Author names in source files |
Previous Message | Tom Lane | 2010-12-03 02:54:01 | Re: should we set hint bits without dirtying the page? |