Re: Remove source code display from \df+?

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remove source code display from \df+?
Date: 2023-01-22 21:28:21
Message-ID: CAMsGm5eZR_KYmP=vX_OzV9_=9T4XKeu0ysKXYoyB_n-OHgeD8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 22 Jan 2023 at 15:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2023-01-22 21:29:41 Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences
Previous Message Jelte Fennema 2023-01-22 21:19:10 Re: run pgindent on a regular basis / scripted manner