Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically
Дата
Msg-id 5063e179-6520-2bf7-36cf-2dfb8c858007@gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns true sporadically  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15492: pg_cancel_backend(pg_backend_pid()) returns truesporadically