Re: [HACKERS] recent deadlock regression test failures
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] recent deadlock regression test failures |
Дата | |
Msg-id | CACjxUsNT4nQCmXEDanzmjewyVtXMyPU-k=6my6zqBqLSt598Tw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] recent deadlock regression test failures (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] recent deadlock regression test failures
|
Список | pgsql-hackers |
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. -- Kevin Grittner
В списке pgsql-hackers по дате отправления: