Re: Fast default stuff versus pg_upgrade
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2018-06-21T01:04:14Z
Lists: 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
Commits
-
Allow for pg_upgrade of attributes with missing values
- 2448adf29c54 11.0 landed