Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Date: 2018-10-12 03:29:28
Message-ID: 8836f4d8-7e93-e223-4e52-701b75463c36@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/11/2018 05:11 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-10-12 04:36:24 Re: Performance improvements for src/port/snprintf.c
Previous Message Michael Paquier 2018-10-12 03:11:58 Re: pgsql: Add TAP tests for pg_verify_checksums