Re: recent deadlock regression test failures

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: recent deadlock regression test failures
Date: 2017-04-08 02:24:40
Message-ID: CAEepm=1fhS993GGgsaCj-UNbubZdb9=MA7rduX2LkZPBhbwMZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 8, 2017 at 9:47 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
>>> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>>
>>>> I'd rather fix the issue, than remove the tests entirely. Seems quite
>>>> possible to handle blocking on Safesnapshot in a similar manner as pg_blocking_pids?
>>>
>>> I'll see what I can figure out.
>>
>> Ouch. These are the other ways I thought of to achieve this:
>>
>> https://www.postgresql.org/message-id/CAEepm%3D1MR4Ug9YsLtOS4Q9KAU9aku0pZS4RhBN%3D0LY3pJ49Ksg%40mail.gmail.com
>>
>> I'd be happy to write one of those, but it may take a day as I have
>> some other commitments.
>
> Please give it a go. I'm dealing with putting out fires with
> customers while trying to make sure I have tested the predicate
> locking GUCs patch sufficiently. (I think it's ready to go, and has
> passed all tests so far, but there are a few more I want to run.)
> I'm not sure I can come up with a solution faster than you, given
> that. Since it is an improvement to performance for a test-only
> environment on a feature that is already committed and not causing
> problems for production environments, hopefully people will tolerate
> a fix a day or two out. If not, we'll have to revert and get it
> into the first CF for v11.

Here is an attempt at option 2 from the menu I posted above. Questions:

1. Does anyone object to this extension of pg_blocking_pids()'s
remit? If so, I could make it a separate function (that was option
3).

2. Did I understand correctly that it is safe to scan the list of
SERIALIZABLEXACTs and access the possibleUnsafeConflicts list while
holding only SerializableXactHashLock, and that 'inLink' is the
correct link to be following?

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

Attachment Content-Type Size
safe-snapshot-blocker-introspection.patch application/octet-stream 6.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2017-04-08 02:36:49 Re: partitioned tables and contrib/sepgsql
Previous Message Tom Lane 2017-04-08 02:23:31 Re: Performance improvement for joins where outer side is unique