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: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel safety of binary_upgrade_create_empty_extension
Date: 2018-03-30 21:09:15
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

I wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>> 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?

> There are some tsquery functions that execute user-supplied queries,
> and so need to be 'u' on the same grounds as the cursor_to_xml cases.
> I haven't checked to be sure if they are already so, but was planning
> to do so before considering this matter closed.

So I looked, and I find that tsquery_rewrite_query, ts_stat1, and
ts_stat2 all execute SQL strings of unknown properties, yet they're
blithely marked parallel safe.

So is contrib/xml2's xpath_table(). The trouble spot there is just
the user-supplied WHERE clause, but that's still a hole big enough
to cause problems. This one's particularly irritating because it'd
require a new extension update script to fix. I'm not sufficiently
excited about it to do that, considering that we've been trying to
deprecate that module for years.

Anyway, that looks like 11 functions that there's no question we
need to relabel. I'll go do that.

I'm still not very happy about the inconsistent marking of the
ruleutils.c functions, but it seems like we don't have consensus
on what to change there.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-30 21:26:21 Re: Parallel safety of binary_upgrade_create_empty_extension
Previous Message Bruce Momjian 2018-03-30 20:52:29 Re: BUG #15112: Unable to run pg_upgrade with earthdistance extension