Re: SERIALIZABLE with parallel query

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SERIALIZABLE with parallel query
Date: 2017-02-15 09:28:13
Message-ID: CAEepm=1wDTnKtj7aY3WTDXJ-8EJb31AzBiZrUVf64kz_gSYxBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Wed, Nov 9, 2016 at 10:51 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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

Attachment Content-Type Size
ssi-parallel-v2.patch application/octet-stream 10.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-02-15 09:30:18 Re: SERIALIZABLE with parallel query
Previous Message Ashutosh Bapat 2017-02-15 09:26:43 Re: Documentation improvements for partitioning