Re: pgsql: Remove pg_class.relhaspkey - Mailing list pgsql-committers

From Andrew Dunstan
Subject Re: pgsql: Remove pg_class.relhaspkey
Date
Msg-id CAA8=A79AxoCVb1kc1aesrfRJVngHhGdNK3RnVuAMKMwKbtPwsA@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Remove pg_class.relhaspkey  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pgsql: Remove pg_class.relhaspkey  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-committers
On Thu, Mar 15, 2018 at 9:41 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.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


pgsql-committers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: pgsql: Support INOUT arguments in procedures
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Move strtoint() to common