From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Shouldn't current_schema() be at least PARALLEL RESTRICTED? |
Date: | 2019-01-19 01:20:52 |
Message-ID: | 20190119012052.GB3306@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 18, 2019 at 03:30:16PM -0500, Robert Haas wrote:
> It seems like, as currently implemented, the function is
> parallel-unsafe, because any inserts, updates, or deletes are
> currently parallel-unsafe, including insertions into catalogs. But I
> am a bit confused why a function that is called current_schema() ends
> up creating a temps schema.
This is documented in namespace.c which needs tricks related to
search_path if referring directly to 'pg_temp', especially if the
namespace creation is marked as pending because its creation cannot
happen outside a transaction context, and the initialization
processing of search_path happens out of that.
Please let me suggest the attached patch then to switch the function
as parallel unsafe, for HEAD. That still seems like the best way of
course for now after sleeping on it.
Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
current-schema-unsafe.patch | text/x-diff | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-01-19 01:33:12 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
Previous Message | Chapman Flack | 2019-01-19 01:20:44 | House style for DocBook documentation? |