On Mon, Apr 10, 2017 at 1:17 PM, 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?
There had better be just a single SERIALIZABLEXACT data structure for a serializable transaction, or it just doesn't work. I can't see how it would have anything but the master's PID in it. If parallel execution is possible in a serializable transaction and things are done any other way, we have a problem. > 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. I have trouble seeing what sane semantics we could possibly have if each worker for a parallel scan used a different snapshot -- under any transaction isolation level. I know that under the read committed transaction isolation level we can follow xmax pointers to hit tuples on the target relation which are not in the snapshot used for the scan, but I don't see how that would negate the need to have the scan itself run on a single snapshot, -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
