Re: Parallel safety of binary_upgrade_create_empty_extension
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-26T22:58:51Z
Lists: pgsql-hackers
... BTW:
# select proname, proparallel from pg_proc where proname like 'binary_upg%';
proname | proparallel
--------------------------------------------+-------------
binary_upgrade_create_empty_extension | r
binary_upgrade_set_next_array_pg_type_oid | r
binary_upgrade_set_next_heap_pg_class_oid | r
binary_upgrade_set_next_index_pg_class_oid | r
binary_upgrade_set_next_pg_authid_oid | r
binary_upgrade_set_next_pg_enum_oid | r
binary_upgrade_set_next_pg_type_oid | r
binary_upgrade_set_next_toast_pg_class_oid | r
binary_upgrade_set_next_toast_pg_type_oid | r
binary_upgrade_set_record_init_privs | r
(10 rows)
I wonder whether we shouldn't mark *all* of these parallel-unsafe.
I'm not exactly convinced that 'restricted' is sufficient for the
others, and even if it is, there's certainly little if any upside
for letting them be executed in parallel-enabled mode.
regards, tom lane
Commits
-
Fix bogus provolatile/proparallel markings on a few built-in functions.
- ea83c7e66fe1 9.5.13 landed
- b7537ffb1ab5 9.4.18 landed
- 91d82317d252 9.6.9 landed
- 485857d447c9 9.3.23 landed
- 283262cd9580 10.4 landed
- 11002f8afa55 11.0 landed