Re: [HACKERS] recent deadlock regression test failures

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] recent deadlock regression test failures
Дата
Msg-id CAEepm=1fhS993GGgsaCj-UNbubZdb9=MA7rduX2LkZPBhbwMZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] recent deadlock regression test failures  (Kevin Grittner <kgrittn@gmail.com>)
Ответы Re: [HACKERS] recent deadlock regression test failures
Re: [HACKERS] recent deadlock regression test failures
Список pgsql-hackers
On Sat, Apr 8, 2017 at 9:47 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>>> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund <andres@anarazel.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Performance improvement for joins where outer side is unique
Следующее
От: Joe Conway
Дата:
Сообщение: Re: [HACKERS] partitioned tables and contrib/sepgsql