Thread

1. Re: meson: Make test output much more useful on failure (both in CI and locally)

   Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-05-17T20:15:55Z

   On Thu Apr 9, 2026 at 11:21 AM CEST, Andrew Dunstan wrote:
   > How about something like this, which would only trigger the behaviour if 
   > an environment variable is set. Also adds that env setting to 
   > cirrus.tasks.yml.
   
   That approach has the problem that then we don't see the diffs anymore
   when pg_regress is called from TAP tests. Attached is a patch that I
   think addresses the problems with the original version.
   
   P.S. For PG20 I intend to submit a patchset that improves the output of
   pg_regress in case of backend crashes. I have a bunch of ideas, but most
   of them require some changes to psql and libpq too.
   

2. Re: meson: Make test output much more useful on failure (both in CI and locally)

   Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-05-18T15:26:05Z

   On Fri Apr 24, 2026 at 7:00 PM CEST, Alexander Lakhin wrote:
   > I've noticed another disadvantage of this log processing: [1] shows the
   > misc_functions test's failure, but we can't see timing of the test anymore:
   > # ok 27        + line                                     6713 ms
   > # ... 210 lines omitted ...
   > # ok 223       + reloptions                              18169 ms
   >
   > Previously, a test report for the same failure contained:
   > ok 139       + merge                                   19699 ms
   > not ok 140   + misc_functions                          18003 ms
   > ok 141       + sysviews                                 7925 ms
   
   I didn't address this in my v6 (yet). Primarily because this isn't
   related to the pg_regress changes, but rather to my change that started
   using command_ok in these tests to run pg_regress. I'm thinking a bit if
   we can make this nicer, one way would be to have command_ok take an
   optional argument that allows disabling truncation in places where we
   know the output won't be huge.
   
   
   
   

3. Re: meson: Make test output much more useful on failure (both in CI and locally)

   Andrew Dunstan <andrew@dunslane.net> — 2026-05-24T22:18:40Z

   On 2026-05-17 Su 4:15 PM, Jelte Fennema-Nio wrote:
   > On Thu Apr 9, 2026 at 11:21 AM CEST, Andrew Dunstan wrote:
   >> How about something like this, which would only trigger the behaviour 
   >> if an environment variable is set. Also adds that env setting to 
   >> cirrus.tasks.yml.
   >
   > That approach has the problem that then we don't see the diffs anymore
   > when pg_regress is called from TAP tests. Attached is a patch that I
   > think addresses the problems with the original version.
   
   
   Why can't the TAP sets set it?
   
   
   cheers
   
   
   andrew
   
   --
   Andrew Dunstan
   EDB: https://www.enterprisedb.com
   
   
   
   
   

4. Re: meson: Make test output much more useful on failure (both in CI and locally)

   Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-05-25T06:20:16Z

   On Mon, May 25, 2026, 00:18 Andrew Dunstan <andrew@dunslane.net> wrote:
   
   > Why can't the TAP sets set it?
   >
   
   The TAP tests could, but then they'd be set indiscriminately for TAP tests.
   Which means Peter's screen will still be flooded when he runs the TAP
   tests.
   
   In general I'd rather make the feature work well enough by default that
   people don't want to disable it.
   
   >
   

5. Re: meson: Make test output much more useful on failure (both in CI and locally)

   Christoph Berg <myon@debian.org> — 2026-05-26T19:19:49Z

   Re: Jelte Fennema-Nio
   > 5. Reduce the default diff truncation limit to 50.
   
   Could we also get a "show everything" mode, perhaps based on an env var?
   
   Debian's build and test machinery doesn't provide means to get at
   files from the build/test run, so all evidence needs to be in the
   build log. The debian/rules file for the PG server currently has this
   contraption:
   
   override_dh_auto_test-arch:
   ifeq (, $(findstring nocheck, $(DEB_BUILD_OPTIONS)))
   	# when tests fail, print newest log files
   	# initdb doesn't like LANG and LC_ALL to contradict, unset LANG and LC_CTYPE here
   	# temp-install wants to be invoked from a top-level make, unset MAKELEVEL here
   	# tell pg_upgrade to create its sockets in /tmp to avoid too long paths
   	unset LANG LC_CTYPE MAKELEVEL; ulimit -c unlimited; \
   	if ! make -C build check-world \
   	  PGSOCKETDIR="/tmp" \
   	  PG_TEST_EXTRA='ssl' \
   	  PROVE_FLAGS="--verbose"; \
   	then \
   	    for l in `find build -name 'regression.*' -o -name '*.log' -o -name '*_log_*' | perl -we 'print map { "$$_\n"; } sort { (stat $$a)[9] <=> (stat $$b)[9] } map { chomp; $$_; } <>' | tail -n 10`; do \
   		echo "******** $$l ********"; \
   		cat $$l; \
   	    done; \
   	    for c in `find build -name 'core*'`; do \
   	        echo "******** $$c ********"; \
   	        gdb -batch -ex 'bt full' build/tmp_install/usr/lib/postgresql/$(MAJOR_VER)/bin/postgres $$c || :; \
   	    done; \
   	    $(TEST_FAIL_COMMAND); \
   	fi
   ifeq ($(WITH_PG_BSD_INDENT),y)
   	$(MAKE) -C build/src/tools/pg_bsd_indent test DESTDIR=$(CURDIR)/debian/tmp
   endif
   endif
   
   The part with the TAP output files is ugly, and the "sort files by
   mtime and show the 10 newest ones" even more so. I would welcome
   anything that allowed me to simplify this.
   
   Thanks,
   Christoph