On Sat, Apr 15, 2023 at 5:15 PM Peter Geoghegan wrote:
> ISTM that b6a0d469ca has created an unmet need for a "--suite
> setup-running", which is analogous to "--suite setup" but works with
> "--setup running". That way there'd at least be a
> "postgresql:setup-running / install_test_files" test
On Sat, Apr 15, 2023 at 4:11 PM Peter Geoghegan wrote:
> $ meson test --setup tmp_install --list | grep install
> postgresql:setup / tmp_install
> postgresql:setup / install_test_files
>
> But not the running setup:
>
> $ meson test --setup running --list | grep install | wc -l
> 0
There is a
On Sat, Apr 15, 2023 at 2:46 PM Justin Pryzby wrote:
> I think what happened is that you (and I) are in the habbit of running
> "meson test tmp_install" to compile new binaries and install them into
> ./tmp_install, and then run a server out from there.
That's not my habit; this is running
On Thu, Apr 13, 2023 at 09:14:01PM -0700, Peter Geoghegan wrote:
> I find that if I run the following test against a standard debug build
> on HEAD, my local installation reliably segfaults:
>
> $ meson test --setup running --suite test_rls_hooks-running
>
> Attached is a "bt full" run from gdb
I find that if I run the following test against a standard debug build
on HEAD, my local installation reliably segfaults:
$ meson test --setup running --suite test_rls_hooks-running
Attached is a "bt full" run from gdb against a core dump. The query
"EXPLAIN (costs off) SELECT * FROM
