Re: Parallel safety of binary_upgrade_create_empty_extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel safety of binary_upgrade_create_empty_extension
Date: 2018-03-26 22:58:51
Message-ID: 23542.1522105131@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-03-26 23:04:27 Re: Parallel safety of binary_upgrade_create_empty_extension
Previous Message Tom Lane 2018-03-26 22:53:32 Re: Parallel safety of binary_upgrade_create_empty_extension