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[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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
