Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Date
Msg-id 9773.1539359331@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 10/12/2018 10:03 AM, Tom Lane wrote:
>> 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.

I'd like a solution that isn't impossibly difficult for manual testing
of cross-version cases, too.  That's why I'd like there to be a regression
test script that does the necessary drops.  Exactly when and how that
gets invoked is certainly open for discussion.  In the manual case
I'd imagine calling it with EXTRA_TESTS while running the setup of
the source database, if it's not run by default.  Maybe the buildfarm
module could just invoke the same script directly at a suitable point?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Multi-insert into a partitioned table with before insert row triggercauses server crash on latest HEAD
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel