On Wed, 2014-11-19 at 11:03 -0500, Robert Haas wrote:
> But your proposal does not solve this problem:
>
> 1. Backend A-1 acquires AccessExclusiveLock on relation R.
> 2. Backend A-2 waits for AccessShareLock on relation R.
>
> The good news is that the deadlock detector should realize that since
> A-1 and A-2 are in the same group, this is a deadlock. And it can
> abort either A-1 or A-2, which will eventually abort them both.
Right. It can even give a nice error hint to tell the user how to avoid
the problem.
> The
> bad news, to borrow a phrase from Peter Geoghegan, is that it's an
> unprincipled deadlock; a user confronted with the news that her
> parallel scan has self-deadlocked will be justifiably dismayed.
You seem to be raising this as a show-stopping problem, and I'm not
convinced that it is.
(a) There are no parallel operators yet, so this is speculative.
(b) Out of the parallel operators you imagine (e.g. Scan), we don't
expect anything other than AccessShare locks in the "normal" case.
(c) The failure mode is not so bad; it's just an error and the user can
probably work around it.
You could argue that we know we're headed for this problem, and
therefore we should solve it now. I disagree. You are assuming that
sharing exclusive heavyweight locks among a group will be a fundamental
part of everything postgres does with parallelism; but not every design
requires it.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
