Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
От | Tom Lane |
---|---|
Тема | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel |
Дата | |
Msg-id | 584811.1725048717@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel (Jelte Fennema-Nio <postgres@jeltef.nl>) |
Ответы |
Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
Re: [EXTERNAL] Re: Add non-blocking version of PQcancel |
Список | pgsql-hackers |
Jelte Fennema-Nio <postgres@jeltef.nl> writes: > On Fri, Aug 30, 2024, 21:21 Tom Lane <tgl@sss.pgh.pa.us> wrote: >> While we're piling on, has anyone noticed that *non* Windows buildfarm >> animals are also failing this test pretty frequently? > Yes. Fixes are here (see the ~10 emails above in the thread for details): > https://www.postgresql.org/message-id/CAGECzQQO8Cn2Rw45xUYmvzXeSSsst7-bcruuzUfMbGQc3ueSdw@mail.gmail.com Hmm. I'm not convinced that 0001 is an actual *fix*, but it should at least reduce the frequency of occurrence a lot, which'd help. I don't want to move the test case to where you propose, because that's basically not sensible. But can't we avoid remote estimates by just cross-joining ft1 to itself, and not using the tables for which remote estimate is enabled? I think 0002 is probably outright wrong, or at least the change to disable_statement_timeout is. Once we get to that, we don't want to throw a timeout error any more, even if an interrupt was received just before it. regards, tom lane
В списке pgsql-hackers по дате отправления: