Re: Parallel safety of binary_upgrade_create_empty_extension - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Parallel safety of binary_upgrade_create_empty_extension
Date
Msg-id CAEepm=0PXid0tj56WC+9bro4VumJo7A8VYoCEiCLOWsWUbNK4A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel safety of binary_upgrade_create_empty_extension  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel safety of binary_upgrade_create_empty_extension  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 28, 2018 at 6:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 27, 2018 at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> regression=# create sequence s1;
>> CREATE SEQUENCE
>> regression=# begin;
>> BEGIN
>> regression=# set force_parallel_mode to 1;
>> SET
>> regression=# declare c cursor for select nextval('s1');
>> DECLARE CURSOR
>> regression=# select cursor_to_xml('c',1,true,true,'');
>> ERROR:  cannot execute nextval() during a parallel operation
>>
>> I think this behavior is a bug.
>
> I agree.

Presumably also cursor_to_xmlschema.  I also found some more
suspicious brin and gin modifying functions.  So I think the list of
functions that needs to be marked 'u' so far is:

* binary_upgrade_create_empty_extension
* pg_import_system_collations
* brin_summarize_range
* brin_summarize_new_values
* brin_desummarize_range
* gin_clean_pending_list
* cursor_to_xml
* cursor_to_xmlschema

Has anyone got anything else?

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] A design for amcheck heapam verification
Next
From: Thomas Munro
Date:
Subject: Re: Typo in shared_record_table_compare() commentary