Re: recent deadlock regression test failures

On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
>> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I notice that the safe-snapshot code path is not paying attention to
>>> parallel-query cases, unlike the lock code path. I'm not sure how
>>> big a deal that is...
>
>> Parallel workers in serializable transactions should be using the
>> transaction number of the "master" process to take any predicate
>> locks, and if parallel workers are doing any DML work against
>> tuples, that should be using the master transaction number for
>> xmin/xmax and serialization failure testing.
>
> Right, but do they record the master's PID rather than their own in
> the SERIALIZABLEXACT data structure?
>
> Maybe it's impossible for a parallel worker to acquire its own
> snapshot at all, in which case this is moot. But I'm nervous.

Parallel workers can't acquire snapshots, and SERIALIZABLE disables
all parallel query planning anyway.

I did some early stage POC hacking to lift that restriction[1], and if
we finish up doing it at all like that then all SERIALIZABLEXACT
structures would be associated with leader processes and
pg_safe_snapshot_blocking_pid() would automatically deal only in
leader PIDs as arguments and results so there would be no problem
here. The interlocking I proposed in that WIP patch may need work, to
be discussed, but I'm fairly sure that sharing the leader's
SERIALIZABLEXACT like that is the only sensible way forward.

[1] https://commitfest.postgresql.org/14/1004/

--
Thomas Munro
http://www.enterprisedb.com