Re: Fast default stuff versus pg_upgrade

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fast default stuff versus pg_upgrade
Date: 2018-06-19 15:51:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 06/19/2018 10:55 AM, Tom Lane wrote:
> AFAICS, the fast-default patch neglected to consider what happens if
> a database containing columns with active attmissingval entries is
> pg_upgraded. I do not see any code in either pg_dump or pg_upgrade that
> attempts to deal with that situation, which means the effect will be
> that the "missing" values will silently revert to nulls: they're still
> null in the table storage, and the restored pg_attribute entries won't
> have anything saying it should be different.
> The pg_upgrade regression test fails to exercise such a case. There is
> only one table in the ending state of the regression database that has
> any atthasmissing columns, and it's empty :-(. If I add a table in
> which there actually are active attmissingval entries, say according
> to the attached patch, I get a failure in the pg_upgrade test.
> This is certainly a stop-ship issue, and in fact it's bad enough
> that I think we may need to pull the feature for v11. Designing
> binary-upgrade support for this seems like a rather large task
> to be starting post-beta1. Nor do I think it's okay to wait for
> v12 to make it work; what if we have to force an initdb later in
> beta, or recommend use of pg_upgrade for some manual catalog fix
> after release?


I guess I have to say mea culpa.

My initial thought was that as a fallback we should disable pg_upgrade
on databases containing such values, and document the limitation in the
docs and the release notes. The workaround would be to force a table
rewrite which would clear them if necessary.

Have we ever recommended use of pg_upgrade for some manual catalog fix
after release? I don't recall doing so. Certainly it hasn't been common.

I have no idea how large an actual fix might be. I'll at least start
working on it immediately. I agree it's very late in the day.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-19 15:53:29 Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Previous Message Andres Freund 2018-06-19 15:50:51 Re: WAL prefetch