Robert Haas escribió: > On Mon, Mar 10, 2014 at 3:33 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Robert Haas escribió: > >> I've committed this patch now with a few further tweaks, leaving this > >> issue unaddressed. It may well be something that needs improvement, > >> but I don't think it's a big enough issue to justify holding back a > >> commit. > > > > Hmm, is the buildfarm exercising any of this? > > I think it isn't, apart from whether it builds. Apparently the > buildfarm only runs installcheck on contrib, not check. And the > test_decoding plugin only runs under installcheck, not check. Also, > it's not going to test walsender/walreceiver at all, but that's harder > to fix.
So the buildfarm exercises pg_upgrade, to some extent, by way of a custom module, https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgrade.pm As far as I can tell, test_decoding wants to do the same thing (i.e. get make check to run). Is the best option to write a new TestLogical.pm module for the buildfarm, or should we somehow think about how to generalize the pg_upgrade trick so that animal caretakers can enable runs of test_decoding by simply upgrading to a newer version of the buildfarm script? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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