From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Remove pg_class.relhaspkey |
Date: | 2018-03-14 23:45:46 |
Message-ID: | CAA8=A79AxoCVb1kc1aesrfRJVngHhGdNK3RnVuAMKMwKbtPwsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Thu, Mar 15, 2018 at 9:41 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> > Basing an MV on pg_class could always be difficult for pg_upgrade. Maybe
>> > that's not a brilliant thing to do in a test (or maybe the test should drop
>> > the MV after it's done).
>>
>> OH. Is that what it's doing? The cause of the failure is immediately
>> obvious then. pg_class now lacks a relhaspkey column, but the matview
>> is still dependent on one being there.
>>
>> I concur that this is not well-considered test design.
>
> It seems very strange to me that the test_ddl_deparse database would be
> used by a pg_upgrade test, but OK. I'll change it.
>
As I mentioned upthread, it's not supposed to be, but was being due to
a typo that I have fixed. You should see this error cleared on the
dashboard in a few minutes.
However, in general the module tries to do a maximal test. That
includes almost all the contrib databases. That approach has helped
reveal problems several times in the past.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-03-15 00:28:51 | Re: pgsql: Move strtoint() to common |
Previous Message | Erik Rijkers | 2018-03-14 23:34:44 | Re: pgsql: Support INOUT arguments in procedures |