pgsql: Move pg_upgrade from contrib/ to src/bin/

On 4/14/15 8:32 PM, Peter Eisentraut wrote:

Move pg_upgrade from contrib/ to src/bin/

Oh dear. It appears the buildfarm client code needs to be updated to
support this. How do we do this? (I guess the critters that are still
green are not running this test.)

Should I revert this patch while we sort this out?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 4/14/15 8:32 PM, Peter Eisentraut wrote:

Move pg_upgrade from contrib/ to src/bin/

Oh dear. It appears the buildfarm client code needs to be updated to
support this. How do we do this? (I guess the critters that are still
green are not running this test.)

Argh..

Looking at the buildfarm client code
(https://github.com/PGBuildFarm/client-code) we are going to need to
make the logic of TestUpgrade.pm aware that pg_upgrade is now in
src/bin and not in contrib. A simple idea would be to use a Find to
guess where pg_upgrade oath is located and then use the path found
instead of hardcoding contrib/.

Should I revert this patch while we sort this out?

I think so, keeping the buildfarm red for a long time is no good...
This is going to require an update of all the buildfarm machines, so
taking the problem at root we had better improve the buildfarm code,
get it deployed on a maximum of machines, and then have this patch
pushed.
It doesn't prevent the other patches in the src/bin to be pushed first
at least, only pg_upgrade has a specific test case.
Regards,
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/15/2015 08:31 AM, Michael Paquier wrote:

On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 4/14/15 8:32 PM, Peter Eisentraut wrote:

Move pg_upgrade from contrib/ to src/bin/

Oh dear. It appears the buildfarm client code needs to be updated to
support this. How do we do this? (I guess the critters that are still
green are not running this test.)

Argh..

Looking at the buildfarm client code
(https://github.com/PGBuildFarm/client-code) we are going to need to
make the logic of TestUpgrade.pm aware that pg_upgrade is now in
src/bin and not in contrib. A simple idea would be to use a Find to
guess where pg_upgrade oath is located and then use the path found
instead of hardcoding contrib/.

I'm testing a fix. I just happened to check the status this morning. It
would have been nice to have had a heads up. The Find idea is cute, I
might have used it if I hadn't already coded a fix.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/15/2015 10:51 AM, Andrew Dunstan wrote:

On 04/15/2015 08:31 AM, Michael Paquier wrote:

On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut <peter_e@gmx.net>
wrote:

On 4/14/15 8:32 PM, Peter Eisentraut wrote:

Move pg_upgrade from contrib/ to src/bin/

Oh dear. It appears the buildfarm client code needs to be updated to
support this. How do we do this? (I guess the critters that are
still
green are not running this test.)

Argh..

Looking at the buildfarm client code
(https://github.com/PGBuildFarm/client-code) we are going to need to
make the logic of TestUpgrade.pm aware that pg_upgrade is now in
src/bin and not in contrib. A simple idea would be to use a Find to
guess where pg_upgrade oath is located and then use the path found
instead of hardcoding contrib/.

I'm testing a fix. I just happened to check the status this morning.
It would have been nice to have had a heads up. The Find idea is cute,
I might have used it if I hadn't already coded a fix.

OK, the fix is here:
<https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2&gt;
and the new TestUpgrade.pm can be grabbed from here:
<https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm&gt;

It can just be dropped into place as a hot fix.

We're overdue for a buildfarm client release, but this hot fix should
get things green again.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan wrote:

OK, the fix is here: <https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2&gt;
and the new TestUpgrade.pm can be grabbed from here: <https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm&gt;

It can just be dropped into place as a hot fix.

We're overdue for a buildfarm client release, but this hot fix should get
things green again.

There's no way we're going to have *everyone* install the hot fix right
away, though, no? Or is people really that quick with updating BF
scripts?

If not, I think it'd be better to revert, get a buildfarm release out,
then push the patch again in a week or so. In the meantime surely we
can push other contrib move patches ...

Regarding the buildfarm update, don't we need a patch for MSVC and
src/test/modules? I remember you (Andrew) and Tom hot-patched
run_build.pm to run those tests, but of course it doesn't work as a
complete release because MSVC doesn't support it. It would be awesome
to get BF patched for both those issues before the next release.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

OK, the fix is here: <https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2&gt; and the new TestUpgrade.pm can be grabbed from here:
<https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm&gt;

It can just be dropped into place as a hot fix.

Hi,

fix applied to capybara is working!

http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=capybara&amp;br=HEAD

(the red on configure was my fault)

Regards,
Chris.

On 04/15/2015 12:23 PM, Alvaro Herrera wrote:

Andrew Dunstan wrote:

OK, the fix is here: <https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2&gt;
and the new TestUpgrade.pm can be grabbed from here: <https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm&gt;

It can just be dropped into place as a hot fix.

We're overdue for a buildfarm client release, but this hot fix should get
things green again.

There's no way we're going to have *everyone* install the hot fix right
away, though, no? Or is people really that quick with updating BF
scripts?

If not, I think it'd be better to revert, get a buildfarm release out,
then push the patch again in a week or so. In the meantime surely we
can push other contrib move patches ...

Regarding the buildfarm update, don't we need a patch for MSVC and
src/test/modules? I remember you (Andrew) and Tom hot-patched
run_build.pm to run those tests, but of course it doesn't work as a
complete release because MSVC doesn't support it. It would be awesome
to get BF patched for both those issues before the next release.

Yes, we do want support for testmodules. I think that needs to be built
into src/tools/msvc, probably in vcregress.pl. Once we have that the
buildfarm changes will be trivial. But if that's not forthcoming quickly
I can just avoid the step on msvc for now.

We've handled the buildfarm being red for a few days before. People are
usually good about applying fixes fairly quickly.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan wrote:

Yes, we do want support for testmodules. I think that needs to be built into
src/tools/msvc, probably in vcregress.pl. Once we have that the buildfarm
changes will be trivial. But if that's not forthcoming quickly I can just
avoid the step on msvc for now.

Well, *I* can't write the MSVC patch, but I can't find anyone to
volunteer some time either :-( I think it's best to have MSVC skip the
step and have the Makefile-based animals run it. That would give us a
lot more coverage than currently, which is just two animals AFAIU.

We've handled the buildfarm being red for a few days before. People are
usually good about applying fixes fairly quickly.

Okay.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Apr 16, 2015 at 4:15 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Andrew Dunstan wrote:

Yes, we do want support for testmodules. I think that needs to be built into
src/tools/msvc, probably in vcregress.pl. Once we have that the buildfarm
changes will be trivial. But if that's not forthcoming quickly I can just
avoid the step on msvc for now.

Well, *I* can't write the MSVC patch, but I can't find anyone to
volunteer some time either :-( I think it's best to have MSVC skip the
step and have the Makefile-based animals run it. That would give us a
lot more coverage than currently, which is just two animals AFAIU.

Meh. I'll just do it then. We've been slacking for some time regarding
that, and it is not cool to have the modules untested on Windows. So
let's do the following:
- Rework the patch doing refactoring of contrib/ and src/test/modules in MSVC.
- Include the modules in install when install target is 'all' or
default, like we did in previous releases.
- Add a new option in vcregress, modulecheck to kick the tests of
those modules. vcregress will need to refactoring as well. This makes
3 patches visibly, one for the build part, one for the install part
and one for vcregress.
Sounds fine?

We've handled the buildfarm being red for a few days before. People are
usually good about applying fixes fairly quickly.

Okay.

I did it on my stuff already...
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Paquier wrote:

On Thu, Apr 16, 2015 at 4:15 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Well, *I* can't write the MSVC patch, but I can't find anyone to
volunteer some time either :-( I think it's best to have MSVC skip the
step and have the Makefile-based animals run it. That would give us a
lot more coverage than currently, which is just two animals AFAIU.

Meh. I'll just do it then. We've been slacking for some time regarding
that, and it is not cool to have the modules untested on Windows.

No kidding.

So let's do the following:
- Rework the patch doing refactoring of contrib/ and src/test/modules in MSVC.
- Include the modules in install when install target is 'all' or
default, like we did in previous releases.
- Add a new option in vcregress, modulecheck to kick the tests of
those modules. vcregress will need to refactoring as well. This makes
3 patches visibly, one for the build part, one for the install part
and one for vcregress.
Sounds fine?

Sounds like a plan.

We've handled the buildfarm being red for a few days before. People are
usually good about applying fixes fairly quickly.

Okay.

I did it on my stuff already...

Great. It's a bit less red already ...

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--On 15. April 2015 15:02:05 -0400 Andrew Dunstan <andrew@dunslane.net>
wrote:

We've handled the buildfarm being red for a few days before. People are
usually good about applying fixes fairly quickly.

Took me some time to get that due to my mail backlog, but i've done the
hotfix for dotterel and forced a run for all branches on this box.

--
Thanks

Bernd

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers