Re: Fast default stuff versus pg_upgrade

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fast default stuff versus pg_upgrade
Date: 2018-06-22 13:01:50
Message-ID: f9fe9c45-7527-2418-50c9-1c7d3a18eade@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/21/2018 04:41 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> I left that for a separate exercise. I think this does things the way
>> you want. I must admit to being a bit surprised, I was expecting you to
>> have more to say about the upgrade function than the pg_dump changes :-)
> Well, the upgrade function is certainly a bit ugly (I'm generally allergic
> to patches that result in a large increase in the number of #includes in
> a file --- it suggests that the code was put in an inappropriate place).
> But I don't see a good way to make it better, at least not without heavy
> refactoring of StoreAttrDefault so that some code could be shared.
>
> I think this is probably OK now, except for one thing: you're likely
> to have issues if a dropped column has an attmissingval, because often
> the value won't agree with the bogus "integer" type we use for those;
> worse, the array might refer to a type that no longer exists.
> One way to improve that is to change
>
> "CASE WHEN a.atthasmissing THEN a.attmissingval "
> "ELSE null END AS attmissingval "
>
> to
>
> "CASE WHEN a.atthasmissing AND NOT a.attisdropped THEN a.attmissingval "
> "ELSE null END AS attmissingval "
>
> However, this might be another reason to reconsider the decision to use
> anyarray: it could easily lead to situations where harmless-looking
> queries like "select * from pg_attribute" fail. Or maybe we should tweak
> DROP COLUMN so that it forcibly resets atthasmissing/attmissingval along
> with setting atthasdropped, so that the case can't arise.
>
> Like Andres, I haven't actually tested, just eyeballed it.
>
>

I moved the bulk of the code into a function in heap.c where it seemed
right at home.

I added removal of missing values from dropped columns, as well as
qualifying the test as above.

The indent issue raised by Alvaro is also fixed. I included your patch
fixing the regression tests.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-06-22 13:28:36 Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.
Previous Message Robert Haas 2018-06-22 12:50:50 Re: "wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.