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
|
| Список | 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 по дате отправления: