Re: [HACKERS] recent deadlock regression test failures
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] recent deadlock regression test failures |
Дата | |
Msg-id | 14232.1491586091@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] recent deadlock regression test failures (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] recent deadlock regression test failures
|
Список | pgsql-hackers |
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 04/07/2017 12:57 PM, Andres Freund wrote: >> I don't think any recent changes are supposed to affect deadlock >> detector behaviour? > Both these machines have CLOBBER_CACHE_ALWAYS set. And on both machines > recent changes have made the isolation tests run much much longer. Ouch. I see friarbird's run time for the isolation tests has gone from an hour and change to over 5 hours in one fell swoop. hyrax not much better. Oddly, non-CCA animals don't seem to have changed much. Eyeing recent patches, it seems like the culprit must be Kevin's addition to isolationtester's wait query: @@ -231,6 +231,14 @@ main(int argc, char **argv) appendPQExpBuffer(&wait_query, ",%s", backend_pids[i]); appendPQExpBufferStr(&wait_query,"}'::integer[]"); + /* Also detect certain wait events. */ + appendPQExpBufferStr(&wait_query, + " OR EXISTS (" + " SELECT * " + " FROM pg_catalog.pg_stat_activity " + " WHERE pid = $1 " + " AND wait_event IN ('SafeSnapshot'))"); + res = PQprepare(conns[0], PREP_WAITING, wait_query.data, 0, NULL); if (PQresultStatus(res) != PGRES_COMMAND_OK) { This seems a tad ill-considered. We sweated a lot of blood not so long ago to get the runtime of that query down, and this seems to have blown it up again. And done so for every isolation test case, not only the ones where it could possibly matter. regards, tom lane
В списке pgsql-hackers по дате отправления: