aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-05-07 13:13:27 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-05-07 13:13:27 -0400
commitf34f0e4c58a31e5edd3aa8a23e171fbcf7e01ff2 (patch)
tree119da6a72c9e45d0b25ae0c4b0141064a0cc7932
parentb56d5f230fae5fccf4fb9f255dfa78b01afed0d9 (diff)
downloadpostgresql-f34f0e4c58a31e5edd3aa8a23e171fbcf7e01ff2.tar.gz
postgresql-f34f0e4c58a31e5edd3aa8a23e171fbcf7e01ff2.zip
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.
-rw-r--r--doc/src/sgml/release-10.sgml20
-rw-r--r--doc/src/sgml/release-9.3.sgml10
-rw-r--r--doc/src/sgml/release-9.4.sgml10
-rw-r--r--doc/src/sgml/release-9.5.sgml10
-rw-r--r--doc/src/sgml/release-9.6.sgml27
5 files changed, 44 insertions, 33 deletions
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index bdaeb95ec59..be37349ec2a 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -106,10 +106,12 @@ Branch: REL9_3_STABLE [485857d44] 2018-03-30 18:14:51 -0400
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>
@@ -146,10 +148,12 @@ Branch: REL9_6_STABLE [91d82317d] 2018-03-30 18:14:51 -0400
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>
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index e8604f99548..4c063551d03 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 627eca168f6..5c93f00e19b 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
index c646be6f9d8..cf7db406f89 100644
--- a/doc/src/sgml/release-9.5.sgml
+++ b/doc/src/sgml/release-9.5.sgml
@@ -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>
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
index 43e7073b980..541afa8ab17 100644
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -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>