On Tue, Mar 27, 2018 at 11:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > # 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.
Yeah, I almost sent a patch to do exactly that, but then I realised the others all just set a global variable so they're technically fine as 'r'. I have no strong preference either way; these functions will only actually be run in parallel in the weird situation of force_parallel_mode = on. -- Thomas Munro http://www.enterprisedb.com
