Postgres Pro
Downloads
Home   >   mailing lists

Re: Remove source code display from \df+? - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Remove source code display from \df+?
Date
Msg-id CAMsGm5eZR_KYmP=vX_OzV9_=9T4XKeu0ysKXYoyB_n-OHgeD8g@mail.gmail.com
Whole thread Raw
In response to Re: Remove source code display from \df+?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove source code display from \df+?
List pgsql-hackers
Tree view
On Sun, 22 Jan 2023 at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Isaac Morland <isaac.morland@gmail.com> writes:
> On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera <alvherre@alvh.no-ip.org>
> wrote:
>> This one would fail the sanity check that all roles created by
>> regression tests need to have names that start with "regress_".

> Thanks for the correction. Now I feel like I've skipped some of the
> readings!
> Updated patch attached. Informally, I am adopting the regress_* policy for
> all object types.

That's excessive.  The policy Alvaro mentions applies to globally-visible
object names (i.e., database, role, and tablespace names), and it's there
to try to ensure that doing "make installcheck" against a live
installation won't clobber any non-test-created objects.  There's no point
in having such a policy within a test database --- its most likely effect
there would be to increase the risk that different test scripts step on
each others' toes.  If you feel a need for a name prefix for non-global
objects, use something based on the name of your test script.

I already used a test-specific prefix, then added "regress_" in front. Point taken, however, on the difference between global and non-global objects.

But now I'm having a problem I don't understand: the CI are still failling, but not in the psql test. Instead, I get this:

[20:11:17.624] +++ tap check in src/bin/pg_upgrade +++
[20:11:17.624] [20:09:11] t/001_basic.pl ....... ok      106 ms ( 0.00 usr  0.00 sys +  0.06 cusr  0.02 csys =  0.08 CPU)
[20:11:17.624]
[20:11:17.624] #   Failed test 'old and new dumps match after pg_upgrade'
[20:11:17.624] #   at t/002_pg_upgrade.pl line 362.
[20:11:17.624] #          got: '1'
[20:11:17.624] #     expected: '0'
[20:11:17.624] # Looks like you failed 1 test of 13.
[20:11:17.624] [20:11:17] t/002_pg_upgrade.pl ..
[20:11:17.624] Dubious, test returned 1 (wstat 256, 0x100)
[20:11:17.624] Failed 1/13 subtests
[20:11:17.624] [20:11:17]
[20:11:17.624]
[20:11:17.624] Test Summary Report
[20:11:17.624] -------------------
[20:11:17.624] t/002_pg_upgrade.pl (Wstat: 256 Tests: 13 Failed: 1)
[20:11:17.624]   Failed test:  13
[20:11:17.624]   Non-zero exit status: 1
[20:11:17.624] Files=2, Tests=21, 126 wallclock secs ( 0.01 usr  0.00 sys +  6.65 cusr  3.95 csys = 10.61 CPU)
[20:11:17.624] Result: FAIL
[20:11:17.624] make[2]: *** [Makefile:55: check] Error 1
[20:11:17.625] make[1]: *** [Makefile:43: check-pg_upgrade-recurse] Error 2

As far as I can tell this is the only failure and doesn’t have anything to do with my change. Unless the objects I added are messing it up? Unlike when the psql regression test was failing, I don’t see an indication of where I can see the diffs.

pgsql-hackers by date:

Previous
From: Jelte Fennema
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: "Karl O. Pinc"
Date:
Subject: Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences