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  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel safety of binary_upgrade_create_empty_extension
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Parallel safety of binary_upgrade_create_empty_extension