On 10/12/2018 10:03 AM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-10-11 17:11:47 -0400, Tom Lane wrote:
>>> 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.
>> To me that seems to be more work / infrastructure than
>> warranted. abstime/reltime/tinterval don't present pg_dump with any
>> special challenges compared to a lot of other types we do test, no?
> Well, in any case I'd say we should put the dropping commands into
> a separate late-stage test script. Whether that's run by default is a
> secondary issue: if it is, somebody who wanted to test this stuff could
> remove the script from their test schedule file.
>
>
Anything that runs at the time we do the regression tests has problems,
from my POV. If we run the drop commands then upgrading these types to a
target <= 11 isn't tested. If we don't run them then upgrade to a
version > 11 will fail. This is why I suggested doing it later in the
buildfarm module that actaally does cross version upgrade testing. It
can drop or not drop prior to running the upgrade test, depending on the
target version.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services