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 exp
On sön, 2011-11-27 at 18:17 -0500, Tom Lane wrote:
> Peter Eisentraut 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 w
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentraut 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
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentraut 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
Peter Eisentraut 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.
I believe t
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
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$
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:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian 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 f
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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?
>
>
Tom Lane wrote:
> Bruce Momjian 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 skip the ch
Bruce Momjian 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 via pgsql-hacke
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 ha
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
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
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 the
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 ex
Peter Eisentraut 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
>> that t
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 i
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 grea
On 09/02/2011 07:49 PM, Tom Lane wrote:
Andrew Dunstan 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 tha
Andrew Dunstan 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 we could possi
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
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 inf
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 r
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 Eisentraut writes:
> >> +# contrib/
On 09/02/2011 03:04 PM, Tom Lane wrote:
Bruce Momjian 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 th
Bruce Momjian 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
> expect
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 Eisentraut writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initialize
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 Eisentraut writes:
> +# contrib/pg_upgrade/test.sh
> +#
> +# Test driver for pg_upgrade. Initializes a new data
Peter Eisentraut wrote:
> On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > +# contrib/pg_upgrade/test.sh
> > > > +#
> > > > +# Test driver for pg_upgrade. Initializes a new database cluster,
> > > > +# runs the regression tests (to
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 Eisentraut writes:
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some
On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut 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,
>
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
Tom Lane wrote:
> Peter Eisentraut 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.
>
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 r
Magnus Hagander writes:
> On Tue, Aug 30, 2011 at 22:25, Tom Lane 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 were to try to back-patch it
>
On Tue, Aug 30, 2011 at 22:25, Tom Lane wrote:
> Peter Eisentraut 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 ag
Peter Eisentraut 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 experience is that t
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 i/contrib/pg_upgrade/
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 setting
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.
> >
>
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: p
On Wed, May 25, 2011 at 3: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 ac
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 t
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 so
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, ea
On Thu, Apr 7, 2011 at 5:20 PM, Peter Eisentraut 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 stuff.
>
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 4:02 PM, 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, easi
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, easily available by typing "make check" and waiting.
It does not yet
51 matches
Mail list logo
