On Fri, Jul 29, 2022 at 7:16 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > That's not the only thing weird about this printout: there should be > three columns not two in that query's output, and what happened to > the trailing newline? I don't think we're looking at desired > output at all.
Well, that's an awfully good point. > I am suspicious that the problem stems from the nonstandard > way you've invoked psql to collect the horizon data. At the very > least this code is duplicating bits of Cluster::psql that it'd be > better not to; and I wonder if the issue is that it's not duplicating > enough. The lack of -X and the lack of use of installed_command() > are red flags. Do you really need to do it like this? Well, I just copied the pg_dump block which occurs directly beforehand and modified it. I think that must take care of setting the path properly, else we'd have things blowing up all over the place. But the lack of -X could be an issue. The missing newline thing happens for me locally too, if I revert the bug fix portion of that commit, but I do seem to get the right columns in the output. It looks like this: 19:24:16.057](0.000s) not ok 16 - old and new horizons match after pg_upgrade [19:24:16.058](0.000s) [19:24:16.058](0.000s) # Failed test 'old and new horizons match after pg_upgrade' # at t/002_pg_upgrade.pl line 345. [19:24:16.058](0.000s) # got: '1' # expected: '0' === diff of /Users/rhaas/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_K8Fs/horizon1.txt and /Users/rhaas/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_K8Fs/horizon2.txt === stdout === 1c1 < pg_largeobject|718|1 --- > pg_largeobject|17518|3=== stderr === === EOF === [19:24:16.066](0.008s) 1..16 I can't account for the absence of a newline there, because hexdump says that both horizon1.txt and horizon2.txt end with one, and if I run diff on those two files and pipe the output into hexdump, it sees a newline at the end of that output too. -- Robert Haas EDB: http://www.enterprisedb.com
