On Wed, Nov 9, 2016 at 10:51 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Need to audit predicate.c for cases where > MySerializableXact might be modified without suitable locking,
The only thing I see along those lines is that CheckForSerializableConflictOut() and CheckForSerializableConflictIn() access SxactIsDoomed(MySerializableXact) without any locking, but if that's OK in the non-parallel case it should also be OK in a worker. I guess this is an opportunistic early error path that doesn't mind seeing data from the past without worrying about cache coherency, on the basis that it will be checked again in PreCommit_CheckForSerializationFailure(). > I wonder what horrible things might happen > as a result of workers running with a SERIALIZABLEXACT that contains > the leader's vxid and other such things. What is the consequence of that vxid? What other complications could be involved here? Here's a rebased patch that updates the documentation and adds a test cast to show a serialization failure being detected when one of the queries runs entirely in a parallel worker. -- Thomas Munro http://www.enterprisedb.com
ssi-parallel-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
