On Sun, 22 Jan 2023 at 17:27, Justin Pryzby <pry...@telsasoft.com> wrote:
> On Sun, Jan 22, 2023 at 04:28:21PM -0500, Isaac Morland wrote: > > On Sun, 22 Jan 2023 at 15:04, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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 +++ > > You'll find the diff in the "artifacts", but not a separate "diff" file. > > https://api.cirrus-ci.com/v1/artifact/task/6146418377752576/testrun/build/testrun/pg_upgrade/002_pg_upgrade/log/regress_log_002_pg_upgrade > > CREATE FUNCTION public.regress_psql_df_sql() RETURNS void > LANGUAGE sql > BEGIN ATOMIC > - SELECT NULL::text; > + SELECT NULL::text AS text; > END; > > It's failing because after restoring the function, the column is named > "text" - maybe it's a bug. > OK, thanks. I'd say I've uncovered a bug related to pg_upgrade, unless I’m missing something. However, I've adjusted my patch so that nothing it creates is kept. This seems tidier even without the test failure. Tom's earlier point was that neither the function nor its owner needs to > be preserved (as is done to exercise pg_dump/restore/upgrade - surely > functions are already tested). Dropping it when you're done running \df > will avoid any possible issue with pg_upgrade. > > Were you able to test with your own github account ? > I haven’t had a chance to try this. I must confess to being a bit confused by the distinction between running the CI tests and doing "make check"; ideally I would like to be able to run all the tests on my own machine without any external resources. But at the same time I don’t pretend to understand the full situation so I will try to use this when I get some time.
0001-Remove-source-code-display-from-df-v6.patch
Description: Binary data
