Re: [HACKERS] recent deadlock regression test failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] recent deadlock regression test failures
Date
Msg-id 17063.1491625324@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] recent deadlock regression test failures  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] recent deadlock regression test failures  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> 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).

It seems an entirely principle-free change in the function's definition.

I'm not actually clear on why Kevin wanted this change in
isolationtester's wait behavior anyway, so maybe some clarification
on that would be a good idea.  But if we need it, I think probably
a dedicated function would be a good thing.  We want the wait-checking
query to be as trivial as possible at the SQL level, so whatever
semantic oddities it needs to have should be pushed into C code.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Remaining 2017-03 CF entries
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Remaining 2017-03 CF entries