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.  (Andres Freund <andres@anarazel.de>)
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:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Next
From: Daniel Gustafsson
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.