Re: [HACKERS] SERIALIZABLE with parallel query

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] SERIALIZABLE with parallel query
Date: 2017-11-30 01:44:12
Message-ID: CAEepm=39THLzokq1fVsUw_iHg0mdp7u0mnRaqUB+juxjcGm8-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 30, 2017 at 2:32 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Nov 24, 2017 at 1:06 PM, Haribabu Kommi
> <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>> The latest patch is good. It lacks a test that verifies the serialize
>> support with actual parallel workers, so in case if it broken, it is
>> difficult to know.
>
> Could this question be answered? The patch still applies so I am
> moving it to next CF.

Thanks. The answer is: It does run queries in two different
backends, proving that different backends associated with the same
session are correctly detecting conflicts and enabling the SSI
algorithm to work. But yeah, Haribabu is right that it doesn't ever
cause them to run simultaneously in a way that would cause the new
locking to contend (or break if the locking code is incorrect). I
have been unable to think of a good way to do that in a regression or
isolation test so far.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-11-30 01:52:14 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Previous Message Amit Langote 2017-11-30 01:43:24 Re: [HACKERS] path toward faster partition pruning