|
91 | 91 | installations will continue to contain the incorrect markings. |
92 | 92 | Practical use of these functions seems to pose little hazard, but in |
93 | 93 | case of trouble, it can be fixed by manually updating these |
94 | | - functions' <structname>pg_proc</structname> entries. (Note that that |
95 | | - will need to be done in each database of the installation.) Another |
96 | | - option is to <application>pg_upgrade</application> the database to a |
97 | | - version containing the corrected initial data. |
| 94 | + functions' <structname>pg_proc</structname> entries, for example |
| 95 | + <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, |
| 96 | + boolean, text) VOLATILE</literal>. (Note that that will need to be |
| 97 | + done in each database of the installation.) Another option is |
| 98 | + to <application>pg_upgrade</application> the database to a version |
| 99 | + containing the corrected initial data. |
98 | 100 | </para> |
99 | 101 | </listitem> |
100 | 102 |
|
|
107 | 109 | <para> |
108 | 110 | The functions |
109 | 111 | <function>brin_summarize_new_values</function>, |
110 | | - <function>brin_summarize_range</function>, |
111 | | - <function>brin_desummarize_range</function>, |
112 | 112 | <function>gin_clean_pending_list</function>, |
113 | 113 | <function>cursor_to_xml</function>, |
114 | 114 | <function>cursor_to_xmlschema</function>, |
115 | 115 | <function>ts_rewrite</function>, |
116 | | - <function>ts_stat</function>, |
117 | | - <function>binary_upgrade_create_empty_extension</function>, and |
118 | | - <function>pg_import_system_collations</function> |
| 116 | + <function>ts_stat</function>, and |
| 117 | + <function>binary_upgrade_create_empty_extension</function> |
119 | 118 | should be marked parallel-unsafe; some because they perform database |
120 | 119 | modifications directly, and others because they execute user-supplied |
121 | 120 | queries that might do so. They were marked parallel-restricted |
|
125 | 124 | incorrect markings. Practical use of these functions seems to pose |
126 | 125 | little hazard unless <varname>force_parallel_mode</varname> is turned |
127 | 126 | on. In case of trouble, it can be fixed by manually updating these |
128 | | - functions' <structname>pg_proc</structname> entries. (Note that that |
129 | | - will need to be done in each database of the installation.) Another |
130 | | - option is to <application>pg_upgrade</application> the database to a |
131 | | - version containing the corrected initial data. |
| 127 | + functions' <structname>pg_proc</structname> entries, for example |
| 128 | + <literal>ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) |
| 129 | + PARALLEL UNSAFE</literal>. (Note that that will need to be done in |
| 130 | + each database of the installation.) Another option is |
| 131 | + to <application>pg_upgrade</application> the database to a version |
| 132 | + containing the corrected initial data. |
132 | 133 | </para> |
133 | 134 | </listitem> |
134 | 135 |
|
|