Re: Parallel safety of binary_upgrade_create_empty_extension

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