Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
От | Jelte Fennema-Nio |
---|---|
Тема | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel |
Дата | |
Msg-id | CAGECzQRqxwcaePLd3MmpZ380CRiCrzPAwmGXsUY9jR5EWf5DLg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
|
Список | pgsql-hackers |
On Thu, 28 Mar 2024 at 19:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > It doesn't fail when it's too fast -- it's just that it doesn't cover > > the case we want to cover. > > That's hardly better, because then you think you have test > coverage but maybe you don't. Honestly, that seems quite a lot better. Instead of having randomly failing builds, you have a test that creates coverage 80+% of the time. And that also seems a lot better than having no coverage at all (which is what we had for the last 7 years since introduction of cancellations to postgres_fdw). It would be good to expand the comment in the test though saying that the test might not always cover the intended code path, due to timing problems. > Could we make this test bulletproof by using an injection point? > If not, I remain of the opinion that we're better off without it. Possibly, and if so, I agree that would be better than the currently added test. But I honestly don't feel like spending the time on creating such a test. And given 7 years have passed without someone adding any test for this codepath at all, I don't expect anyone else will either. If you both feel we're better off without the test, feel free to remove it. This was just some small missing test coverage that I noticed while working on this patch, that I thought I'd quickly address. I don't particularly care a lot about the specific test.
В списке pgsql-hackers по дате отправления: