Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically - Mailing list pgsql-bugs

From Alexander Lakhin
Subject Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically
Date
Msg-id 5063e179-6520-2bf7-36cf-2dfb8c858007@gmail.com
Whole thread Raw
In response to Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns true sporadically  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically
List pgsql-bugs
09.11.2018 17:49, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Fri, Nov 9, 2018 at 2:21 AM Michael Paquier <michael@paquier.xyz> wrote:
>>> On Thu, Nov 08, 2018 at 11:31:41AM +0100, Magnus Hagander wrote:
>>>> ... why is this problem only showing up now?
>> Oh, i didn't realize that wasn't run by the buildfarm. Then yeah, it's
>> pretty likely it was simply never run.
> IIRC, the reason those tests aren't run by default is that they're
> pointless unless executed in a hot-standby configuration.  I'm inclined to
> think we should remove them from src/test/regress altogether, and instead
> put equivalent checks (for any not-already-covered case) into one of the
> TAP tests that sets up such a configuration.  src/test/recovery is
> probably the right home.
I tried to use the 'make standycheck' approach for two reasons. First,
it's documented at https://www.postgresql.org/docs/11/regress-run.html
Second, it allows to test a replication between different minor versions
(after some setup).
Will we still have such a possibility, if the tests will be removed?

Best regards,
Alexander



pgsql-bugs by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically