Re: Parallel safety of binary_upgrade_create_empty_extension
От | Tom Lane |
---|---|
Тема | Re: Parallel safety of binary_upgrade_create_empty_extension |
Дата | |
Msg-id | 23542.1522105131@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Parallel safety of binary_upgrade_create_empty_extension (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Parallel safety of binary_upgrade_create_empty_extension
|
Список | 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
В списке pgsql-hackers по дате отправления: