Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
| Дата | |
| Msg-id | 9773.1539359331@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
| Список | 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 по дате отправления: