Thread: Re: [COMMITTERS] 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?
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
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
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> and the new TestUpgrade.pm can be grabbed from here: <https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm> 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
Andrew Dunstan wrote: > OK, the fix is here: <https://github.com/PGBuildFarm/client-code/commit/47b24efa758360699413640dd14c4096e1643fb2> > and the new TestUpgrade.pm can be grabbed from here: <https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm> > > 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
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> >> and the new TestUpgrade.pm can be grabbed from here: <https://raw.githubusercontent.com/PGBuildFarm/client-code/47b24efa758360699413640dd14c4096e1643fb2/PGBuild/Modules/TestUpgrade.pm> >> >> 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
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
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
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
--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