Robert Haas <robertmh...@gmail.com> writes: > On Wed, Feb 17, 2016 at 9:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I just had a rather disturbing thought to the effect that this entire >> design --- ie, parallel workers taking out locks for themselves --- is >> fundamentally flawed. As far as I can tell from README.parallel, >> parallel workers are supposed to exit (and, presumably, release their >> locks) before the leader's transaction commits. Releasing locks before >> commit is wrong. Do I need to rehearse why?
> No, you don't. I've spent a good deal of time thinking about that problem. > [ much snipped ] > Unless I'm missing something, though, this is a fairly obscure > problem. Early release of catalog locks is desirable, and locks on > scanned tables should be the same locks (or weaker) than already held > by the master. Other cases are rare. I think. It would be good to > know if you think otherwise. After further thought, what I think about this is that it's safe so long as parallel workers are strictly read-only. Given that, early lock release after user table access is okay for the same reasons it's okay after catalog accesses. However, this is one of the big problems that we'd have to have a solution for before we ever consider allowing read-write parallelism. So what distresses me about the current situation is that this is a large stumbling block that I don't see documented anywhere. It'd be good if you transcribed some of this conversation into README.parallel. (BTW, I don't believe your statement that transferring locks back to the master would be deadlock-prone. If the lock system treats locks held by a lock group as effectively all belonging to one entity, then granting a lock identical to one already held by another group member should never fail. I concur that it might be expensive performance-wise, though it hardly seems like this would be a dominant factor compared to all the other costs of setting up and tearing down parallel workers.) regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers