On 15 October 2014 14:46, Robert Haas <robertmhaas@gmail.com> wrote:
>> When my family goes to a restaurant, any member of the party may ask
>> for a table and the request is granted for the whole family. But the
>> lock is released only when I pay the bill. Once we have the table, any
>> stragglers know we have locked the table and they just come sit at the
>> table without needing to make their own lock request to the Maitre D',
>> though they clearly cache the knowledge that we have the table locked.
> Hmm, interesting idea. Suppose, though, that the child process
> requests a lock that can't immediately be granted, because the catalog
> it's trying to access is locked in AccessExclusiveLock mode by an
> unrelated transaction. The unrelated transaction, in turn, is blocked
> trying to acquire some resource, which the top level parallelism
> process. Assuming the top level parallelism process is waiting for
> the child (or will eventually wait), this is a deadlock, but without
> some modification to the deadlock detector, it can't see one of the
> edges.
Family disputes are fairly easily resolved ;-)
The first and basic point is that in most cases the parent should
already hold the required locks. This can only happen for briefly held
locks and/or more complex stuff. In the first case, getting
parallelism to work without that complex stuff would be useful. I'd be
happy if the first version simply throws an error if a child can't
acquire a lock immediately. Don't overthink the first version. Knowing
you'll disagree, lets take a further step...
Second point, the relationship between parent and children is clear.
If we do a deadlock detection, we should be able to search for that as
a special case, since we will know that we are a child and that such a
situation might occur. So just add in an edge so the rest of the
deadlock code works fine.
If that doesn't work, use a heurisic. If parent is waiting when child
does deadlock test, assume its a deadlock and abort the child
speculatively just in case. You can work out how to do that better in
the future, since it won't happen that often.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
