Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 17, 2016 at 9:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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