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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Date: 2018-10-12 15:48:51
Message-ID: 9773.1539359331@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-10-12 15:58:21 Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Previous Message Ashutosh Sharma 2018-10-12 15:46:25 Multi-insert into a partitioned table with before insert row trigger causes server crash on latest HEAD