Last-minute updates for release notes.

The set of functions that need parallel-safety adjustments isn't the
same in 9.6 as 10, so I shouldn't have blindly back-patched that list.
Adjust as needed.  Also, provide examples of the commands to issue.
This commit is contained in:
Tom Lane 2018-05-07 13:13:27 -04:00
parent 2a771988f4
commit e71d9f6951
4 changed files with 32 additions and 25 deletions

View File

@ -59,10 +59,12 @@
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
functions' <structname>pg_proc</structname> entries, for example
<literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
boolean, text) VOLATILE</literal>. (Note that that will need to be
done in each database of the installation.) Another option is
to <application>pg_upgrade</application> the database to a version
containing the corrected initial data.
</para>
</listitem>

View File

@ -59,10 +59,12 @@
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
functions' <structname>pg_proc</structname> entries, for example
<literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
boolean, text) VOLATILE</literal>. (Note that that will need to be
done in each database of the installation.) Another option is
to <application>pg_upgrade</application> the database to a version
containing the corrected initial data.
</para>
</listitem>

View File

@ -59,10 +59,12 @@
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
functions' <structname>pg_proc</structname> entries, for example
<literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
boolean, text) VOLATILE</literal>. (Note that that will need to be
done in each database of the installation.) Another option is
to <application>pg_upgrade</application> the database to a version
containing the corrected initial data.
</para>
</listitem>

View File

@ -91,10 +91,12 @@
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
functions' <structname>pg_proc</structname> entries, for example
<literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
boolean, text) VOLATILE</literal>. (Note that that will need to be
done in each database of the installation.) Another option is
to <application>pg_upgrade</application> the database to a version
containing the corrected initial data.
</para>
</listitem>
@ -107,15 +109,12 @@
<para>
The functions
<function>brin_summarize_new_values</function>,
<function>brin_summarize_range</function>,
<function>brin_desummarize_range</function>,
<function>gin_clean_pending_list</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>ts_rewrite</function>,
<function>ts_stat</function>,
<function>binary_upgrade_create_empty_extension</function>, and
<function>pg_import_system_collations</function>
<function>ts_stat</function>, and
<function>binary_upgrade_create_empty_extension</function>
should be marked parallel-unsafe; some because they perform database
modifications directly, and others because they execute user-supplied
queries that might do so. They were marked parallel-restricted
@ -125,10 +124,12 @@
incorrect markings. Practical use of these functions seems to pose
little hazard unless <varname>force_parallel_mode</varname> is turned
on. In case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
functions' <structname>pg_proc</structname> entries, for example
<literal>ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass)
PARALLEL UNSAFE</literal>. (Note that that will need to be done in
each database of the installation.) Another option is
to <application>pg_upgrade</application> the database to a version
containing the corrected initial data.
</para>
</listitem>