On Wed, Nov 9, 2016 at 10:51 AM, Thomas Munro
<thomas.munro@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
