Re: Fast default stuff versus pg_upgrade - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Fast default stuff versus pg_upgrade
Date
Msg-id 20180621010414.6gviy5hfyz2f3bub@alap3.anarazel.de
Whole thread Raw
In response to Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Fast default stuff versus pg_upgrade
List pgsql-hackers
Hi,

On 2018-06-20 20:53:34 -0400, Andrew Dunstan wrote:
> This version adds a lock on the table owning the attribute.

Cool.
>  
>          /*
> +         * in binary upgrade mode, update the catalog with any missing values
> +         * that might be present.
> +         */
> +        if (dopt->binary_upgrade)
> +        {
> +            for (j = 0; j < tbinfo->numatts; j++)
> +            {
> +                if (tbinfo->atthasmissing[j])
> +                {
> +                    appendPQExpBufferStr(q, "\n-- set missing value.\n");
> +                    appendPQExpBufferStr(q,
> +                                         "SELECT pg_catalog.binary_upgrade_set_missing_value(");
> +                    appendStringLiteralAH(q,qualrelname, fout);

missing space.  Probably couldn't hurt to run the changed files through
pgindent and fix the damage...

> +                    appendPQExpBufferStr(q, "::pg_catalog.regclass,");
> +                    appendStringLiteralAH(q, tbinfo->attnames[j], fout);
> +                    appendPQExpBufferStr(q,",");

same.


> +                    appendStringLiteralAH(q, tbinfo->attmissingval[j], fout);
> +                    appendPQExpBufferStr(q,");\n\n");

same.


Looks reasonable to me, but I've not tested it.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fast default stuff versus pg_upgrade
Next
From: Masahiko Sawada
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)