Re: SERIALIZABLE with parallel query

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SERIALIZABLE with parallel query
Date: 2017-06-27 23:21:38
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Apr 4, 2017 at 8:25 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> ... but considering that these data structures may
> finish up being redesigned as part of the GSoC project[1], it may be
> best to wait and see where that goes before doing anything. I'll
> follow developments there, and if this patch remains relevant I'll
> plan to do some more work on it including testing (possibly with the
> RUBiS benchmark from Kevin and Dan's paper since it seems the most
> likely to be able to really use parallelism) for PG11 CF1.

I've been keeping one eye on the GSoC project. That patch changes the
inConflicts and outConflicts data structures, but not the locking
protocol. This patch works by introducing per-SERIALIZABLEXACT
locking in the places where the code currently assumes that the
current backend is the only one that could modify a shared data
structure (namely MySerializableXact->predicateLocks), so that
MySerializableXact can be shared with workers. There doesn't seem to
be any incompatibility or dependency so far, so here's a rebased
patch. Testing needed.

Thomas Munro

Attachment Content-Type Size
ssi-parallel-v5.patch application/octet-stream 18.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2017-06-27 23:45:31 Re: transition table behavior with inheritance appears broken
Previous Message Andres Freund 2017-06-27 21:13:28 Re: Fast promotion not used when doing a recovery_target PITR restore?