Re: Fast default stuff versus pg_upgrade
От | Andres Freund |
---|---|
Тема | Re: Fast default stuff versus pg_upgrade |
Дата | |
Msg-id | 20180621010414.6gviy5hfyz2f3bub@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Fast default stuff versus pg_upgrade (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: Fast default stuff versus pg_upgrade
|
Список | 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 по дате отправления: