On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Kevin Grittner <kgri...@gmail.com> writes:
>> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <t...@sss.pgh.pa.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, 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.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: