On sön, 2011-11-27 at 18:17 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could
On sön, 2011-11-27 at 19:12 -0500, Andrew Dunstan wrote:
Contrib tests are only run by the buildfarm in installcheck mode, so
that will probably turn the tests off for the buildfarm, so +1 on that
Does the new buildfarm modular thing support that some members could run
the checks through
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could create a way
On lör, 2011-11-05 at 18:45 +0200, Peter Eisentraut wrote:
On mån, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
I found a simpler way to get this working. Just hack up the catalogs
for the new path directly. So I can now run this test suite against
older versions as well, like this:
Peter Eisentraut pete...@gmx.net writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could create a way to
omit the test if it becomes a problem.
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could create a way
Peter Eisentraut wrote:
On m?n, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
I found a simpler way to get this working. Just hack up the catalogs
for the new path directly. So I can now run this test suite against
older versions as well, like this:
contrib/pg_upgrade$ make
On mån, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
I found a simpler way to get this working. Just hack up the catalogs
for the new path directly. So I can now run this test suite against
older versions as well, like this:
contrib/pg_upgrade$ make installcheck oldsrc=somewhere
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I propose I just remove the 8.4
test and always allow toast table names not to match --- the oids are
still checked and are preserved.
+1. You'll still make the check for non-toast tables, of course?
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I propose I just remove the 8.4
test and always allow toast table names not to match --- the oids are
still checked and are preserved.
+1. You'll still make the check for
Bruce Momjian wrote:
Peter Eisentraut wrote:
8.4 - master upgrade fails like this:
Restoring user relation files
Mismatch of relation names in database regression: old name
pg_toast.pg_toast_27437, new name pg_toast.pg_toast_27309
Failure, exiting
This has been 100%
Bruce Momjian br...@momjian.us writes:
I propose I just remove the 8.4
test and always allow toast table names not to match --- the oids are
still checked and are preserved.
+1. You'll still make the check for non-toast tables, of course?
regards, tom lane
--
Sent
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I propose I just remove the 8.4
test and always allow toast table names not to match --- the oids are
still checked and are preserved.
+1. You'll still make the check for non-toast tables, of course?
Yes, only toast tables will
Peter Eisentraut wrote:
8.4 - master upgrade fails like this:
Restoring user relation files
Mismatch of relation names in database regression: old name
pg_toast.pg_toast_27437, new name pg_toast.pg_toast_27309
Failure, exiting
This has been 100% reproducible for me.
I can now reproduce
On mån, 2011-09-05 at 23:42 +0300, Peter Eisentraut wrote:
On lör, 2011-09-03 at 19:58 -0400, Tom Lane wrote:
Anyway, after giving up on that I went back to plan A, namely install
regress.so and friends into $libdir. That turns out to be really quite
straightforward, though I had to hack
On lör, 2011-09-03 at 19:58 -0400, Tom Lane wrote:
Anyway, after giving up on that I went back to plan A, namely install
regress.so and friends into $libdir. That turns out to be really quite
straightforward, though I had to hack pg_regress.c a bit to get its idea
of $libdir to match up
On 09/03/2011 07:58 PM, Tom Lane wrote:
Anyway, after giving up on that I went back to plan A, namely install
regress.so and friends into $libdir. That turns out to be really quite
straightforward, though I had to hack pg_regress.c a bit to get its idea
of $libdir to match up exactly with
On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote:
The only one that's problematic is pg_regress.so; contrib modules are
already installed in $libdir. I still think that installing
pg_regress.so in $libdir may be the most reasonable solution, assuming
that the delta involved isn't too great.
Peter Eisentraut wrote:
But if you think about it, it doesn't really test pg_upgrade, it tests
pg_dump. So the test could just as well be moved to src/bin/pg_dump/
and be labeled pg_dump smoke test or whatever. (Minor detail: The bug
fix above involved the --binary-upgrade flag, so it is
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote:
The only one that's problematic is pg_regress.so; contrib modules are
already installed in $libdir. I still think that installing
pg_regress.so in $libdir may be the most reasonable solution, assuming
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some data), runs pg_dumpall,
On 09/02/2011 10:36 AM, Peter Eisentraut wrote:
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests
Peter Eisentraut wrote:
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put
Andrew Dunstan wrote:
On 09/02/2011 10:36 AM, Peter Eisentraut wrote:
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database
On 09/02/2011 01:55 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 09/02/2011 10:36 AM, Peter Eisentraut wrote:
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for
Bruce Momjian br...@momjian.us writes:
Andrew Dunstan wrote:
In any case, it would be good to get rid of the limitation if possible.
Then we could look at creating an automated test that we could use in
the buildfarm.
Well, the idea of using the catalog version was that it is something we
On 09/02/2011 03:04 PM, Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
Andrew Dunstan wrote:
In any case, it would be good to get rid of the limitation if possible.
Then we could look at creating an automated test that we could use in
the buildfarm.
Well, the idea of using the
Andrew Dunstan wrote:
On 09/02/2011 01:55 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 09/02/2011 10:36 AM, Peter Eisentraut wrote:
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
+#
On fre, 2011-09-02 at 16:00 -0400, Andrew Dunstan wrote:
Basically the idea is to stash away build and data dirs (after we've run
regression, PL and contrib testing) for stable branches (via a command
line option) and then test upgrading them. A trial run on the first part
is currently
On fre, 2011-09-02 at 15:04 -0400, Tom Lane wrote:
IMO there's next to no value in testing that scenario anyway, since
nobody would ever use it in the field. What *would* be of value is
testing upgrades from previous release versions. Probably that will
take some work in the buildfarm
On 09/02/2011 06:37 PM, Peter Eisentraut wrote:
On fre, 2011-09-02 at 16:00 -0400, Andrew Dunstan wrote:
Basically the idea is to stash away build and data dirs (after we've run
regression, PL and contrib testing) for stable branches (via a command
line option) and then test upgrading them. A
Andrew Dunstan and...@dunslane.net writes:
On 09/02/2011 06:37 PM, Peter Eisentraut wrote:
It won't work, unless you have a solution for fixing the paths of the
shared library modules used by the regression tests.
Well, we could drop those functions and not run tests that require them.
Or
On 09/02/2011 07:49 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 09/02/2011 06:37 PM, Peter Eisentraut wrote:
It won't work, unless you have a solution for fixing the paths of the
shared library modules used by the regression tests.
Well, we could drop those functions
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some data), runs pg_dumpall,
+# runs pg_upgrade, runs pg_dumpall again, compares the
Peter Eisentraut wrote:
On tis, 2011-08-30 at 16:25 -0400, Tom Lane wrote:
So I think that as given, this script is only useful for testing
pg_upgrade of $currentversion to $currentversion. Which is surely
better than no test at all, but it would not for example have caught
the 8.3
On tis, 2011-08-30 at 16:25 -0400, Tom Lane wrote:
So I think that as given, this script is only useful for testing
pg_upgrade of $currentversion to $currentversion. Which is surely
better than no test at all, but it would not for example have caught
the 8.3 incompatibility that was just
Here is an updated version of the pg_upgrade test script I posted a
while ago. I've cleaned it up so that it offers moderately
user-friendly feedback, it supports check and installcheck mode, and
should use all the things from the right directories in either case.
diff --git
Peter Eisentraut pete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some data), runs pg_dumpall,
+# runs pg_upgrade, runs pg_dumpall again, compares the dumps.
Hm .. my
On Tue, Aug 30, 2011 at 22:25, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some data), runs pg_dumpall,
+# runs
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 30, 2011 at 22:25, Tom Lane t...@sss.pgh.pa.us wrote:
How can we improve things here? I've toyed with the idea of installing
pg_regress.so so that we can refer to it relative to $libdir, but that
might be a bit invasive, especially if we
On 05/25/2011 03:07 PM, Peter Eisentraut wrote:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it fails if
you have another postmaster running on port 5432.
This has now been addressed: pg_upgrade accepts PGPORT
Noah Misch wrote:
On Wed, May 25, 2011 at 10:07:45PM +0300, Peter Eisentraut wrote:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it
fails if
you have another postmaster running on port 5432.
This has now
On Wed, May 25, 2011 at 10:07:45PM +0300, Peter Eisentraut wrote:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it
fails if
you have another postmaster running on port 5432.
This has now been addressed:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it fails
if
you have another postmaster running on port 5432.
This has now been addressed: pg_upgrade accepts PGPORT settings.
Attached is a slightly updated patch runs the
On Wed, May 25, 2011 at 3:07 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
Enthusiastic +1 for this concept. There's at least one rough edge: it fails
if
you have another postmaster running on port 5432.
This has now been addressed:
On tor, 2011-04-07 at 23:02 +0300, Peter Eisentraut wrote:
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is something I hacked together that at least exposes the
current problems,
On Wed, Apr 27, 2011 at 09:32:16PM +0300, Peter Eisentraut wrote:
On tor, 2011-04-07 at 23:02 +0300, Peter Eisentraut wrote:
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is
On Thu, Apr 7, 2011 at 4:02 PM, Peter Eisentraut pete...@gmx.net wrote:
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is something I hacked together that at least exposes the
current
On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
I think it's a worthwhile thing to do, but right now I think it would
be more helpful if you could help fix the breakage your patch created,
rather than working on new stuff.
This is part of that.
--
Sent via pgsql-hackers mailing list
On Thu, Apr 7, 2011 at 5:20 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
I think it's a worthwhile thing to do, but right now I think it would
be more helpful if you could help fix the breakage your patch created,
rather than working on new
50 matches
Mail list logo
