Re: Changeset Extraction v7.9.1
От | Alvaro Herrera |
---|---|
Тема | Re: Changeset Extraction v7.9.1 |
Дата | |
Msg-id | 20140310211603.GN4759@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Changeset Extraction v7.9.1 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas escribió: > On Mon, Mar 10, 2014 at 3:33 PM, Alvaro Herrera > <alvherre@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
В списке pgsql-hackers по дате отправления: