On 15 October 2014 14:46, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
