Re: pgsql: Add 'basebackup_to_shell' contrib module. - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: pgsql: Add 'basebackup_to_shell' contrib module. |
Date | |
Msg-id | 20220326205135.e47br5qj7urgqoqy@alap3.anarazel.de Whole thread Raw |
In response to | Re: pgsql: Add 'basebackup_to_shell' contrib module. (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: pgsql: Add 'basebackup_to_shell' contrib module.
|
List | pgsql-hackers |
Hi, On 2022-03-26 16:24:32 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Sat, Mar 26, 2022 at 3:35 PM Andres Freund <andres@anarazel.de> wrote: > >> === tap tests in src/bin/pg_resetwal === > >> t/001_basic.pl ...... ok > >> t/002_corrupted.pl .. ok > >> All tests successful. > > > Yeah, this certainly seems like an improvement to me. Do we want to do the same of regress and isolation tests? They're mostly a bit easier to place, but it's still a memory retention game. Using the above format for all looks a tad weird, due to pg_regress' output having kinda similar markers. ... ====================== All 22 tests passed. ====================== === regress tests in contrib/ltree_plpython" === ============== creating temporary instance ============== ============== initializing database system ============== ============== starting postmaster ============== running on port 51696 with PID 3905518 ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== installing ltree ============== CREATE EXTENSION ============== running regression test queries ============== test ltree_plpython ... ok 51 ms ============== shutting down postmaster ============== ============== removing temporary instance ============== ... Could just use a different character. +++ doesn't look bad: +++ tap tests in contrib/test_decoding +++ t/001_repl_stats.pl .. ok All tests successful. Files=1, Tests=2, 3 wallclock secs ( 0.02 usr 0.00 sys + 1.74 cusr 0.28 csys = 2.04 CPU) Result: PASS Would we want to do this in all branches? I'd vote for yes, but ... Prototype patch attached. I looked through the uses of pg_(isolation_)?regress_(install)?check' and didn't find any that'd have a problem with turning the invocation into a multi-command one. > +1, but will it help for CI Yes, it should make it considerably better (for everything but windows, but that outputs separators already). > or buildfarm cases? Probably not much, because that largely runs tests serially with "stage" names corresponding to the test. And when it runs multiple tests in a row it adds something similar to the above, e.g.: =========== Module pg_stat_statements check ============= https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=peripatus&dt=2022-03-26%2000%3A20%3A30&stg=misc-check But I think it'll still be a tad better when it runs a single test: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=snapper&dt=2022-03-26%2018%3A46%3A28&stg=subscription-check Might make it more realistic to make -s, at least to run tests? The reams of output like: gmake -C ../../../../src/test/regress pg_regress gmake[1]: Entering directory '/home/pgbuildfarm/buildroot/HEAD/pgsql.build/src/test/regress' gmake -C ../../../src/port all gmake[2]: Entering directory '/home/pgbuildfarm/buildroot/HEAD/pgsql.build/src/port' gmake[2]: Nothing to be done for 'all'. gmake[2]: Leaving directory '/home/pgbuildfarm/buildroot/HEAD/pgsql.build/src/port' gmake -C ../../../src/common all gmake[2]: Entering directory '/home/pgbuildfarm/buildroot/HEAD/pgsql.build/src/common' gmake[2]: Nothing to be done for 'all'. are quite clutter-y. Greetings, Andres Freund
Attachment
pgsql-hackers by date: