On 10/11/2018 05:11 PM, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
On 2018-10-11 16:57:02 -0400, Tom Lane wrote:
Another idea would be to put table drops into the back branch regression
tests, so that their ending states don't include any such tables. That
would cripple pg_dump testing of these types in the back branches, but
I'm not sure if we really care much.
I think the latter is the better choice. Given the code for those types
hasn't changed meaningfully in the last decade, I think not having
pg_dump coverage would be ok.
I don't especially like either of these choices --- anyone got another
idea?
Nope :(
A compromise that occurred to me after a bit of reflection is to place
the necessary table-drop commands in a new regression test script that's
meant to be executed last, but isn't actually run by default. Then
teach the cross-version-update test script to include that script via
EXTRA_TESTS. Manual testing could do likewise. Then we have a small
amount of pain for testing upgrades, but we lose no test coverage in
back branches.
That's not how it works. The module doesn't itself run the regression
tests. It uses saved data from a normal buildfarm run against the
version being upgraded from.
It does, however, do some fixups along the way. See
<https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgradeXversion.pm>
around line 315.
We could have it do something there, if the target branch was > 11. That
way these things would still be tested for in an upgrade to any version
that supports them.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
