Re: Let's invent a function to report lock-wait-blocking PIDs
От | Alvaro Herrera |
---|---|
Тема | Re: Let's invent a function to report lock-wait-blocking PIDs |
Дата | |
Msg-id | 20130320183712.GE3688@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Let's invent a function to report lock-wait-blocking PIDs (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas escribió: > On Wed, Mar 20, 2013 at 2:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm > > critters aren't managing to run the new "timeouts" isolation test > > successfully, despite very generous timeouts. The answer is that > > 2 seconds isn't quite enough time to parse+plan+execute the query > > that isolationtester uses to see if the current test session is > > blocked on a lock, if CLOBBER_CACHE_ALWAYS is on. Now, that query > > is totally horrible: > > In the isolationtester use-case, we'd get the right answer by testing > > whether this function's result has any overlap with the set of PIDs of > > test sessions, ie > > > > select pg_blocking_pids($1) && array[pid1, pid2, pid3, ...] > > Sounds excellent. Yeah, I have looked at that query a couple of times wondering how it could be improved and came up blank. Glad you had a reason to be in the area. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: