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
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 |