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
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 |