pg_upgrade regression test litters the source tree with log files
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)
Not sure how long this has been happening.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)Not sure how long this has been happening.
Those look like files left over from a failed upgrade, or you used
--retain. Does that make sense? Because they are tracked by oid, it
is possible a later successful upgrade would not remove all those files,
bit it should remove contrib/pg_upgrade/pg_upgrade_dump_1.log because it
is "1".
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)Not sure how long this has been happening.
Those look like files left over from a failed upgrade, or you used
--retain. Does that make sense?
It's possible that I had one or more failed regression test runs on that
machine ... don't recall for sure. In any case the point here is that
"make clean" ought to get rid of anything that might be left over from a
test run, successful or otherwise.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/8/13 4:04 PM, Bruce Momjian wrote:
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)Not sure how long this has been happening.
Those look like files left over from a failed upgrade, or you used
--retain. Does that make sense? Because they are tracked by oid, it
is possible a later successful upgrade would not remove all those files,
bit it should remove contrib/pg_upgrade/pg_upgrade_dump_1.log because it
is "1".
I think this came in with the pg_upgrade --jobs option.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 04:08:42PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)Not sure how long this has been happening.
Those look like files left over from a failed upgrade, or you used
--retain. Does that make sense?It's possible that I had one or more failed regression test runs on that
machine ... don't recall for sure. In any case the point here is that
"make clean" ought to get rid of anything that might be left over from a
test run, successful or otherwise.
That seems like something more for the regression script (test.sh) to
delete. Those are output by _running_ the program, and I never expected
people to be running it in the git tree.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 8, 2013 at 04:11:41PM -0500, Peter Eisentraut wrote:
On 1/8/13 4:04 PM, Bruce Momjian wrote:
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
In a tree in which I previously ran "make check" in contrib/pg_upgrade:
$ make -s distclean
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# contrib/pg_upgrade/pg_upgrade_dump_1.log
# contrib/pg_upgrade/pg_upgrade_dump_12912.log
# contrib/pg_upgrade/pg_upgrade_dump_16384.log
nothing added to commit but untracked files present (use "git add" to track)Not sure how long this has been happening.
Those look like files left over from a failed upgrade, or you used
--retain. Does that make sense? Because they are tracked by oid, it
is possible a later successful upgrade would not remove all those files,
bit it should remove contrib/pg_upgrade/pg_upgrade_dump_1.log because it
is "1".I think this came in with the pg_upgrade --jobs option.
Yes, it was part of the split to allow creation of per-database SQL
files, but pg_upgrade always created files in the current directory ---
there are just more of them now.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers