Re: Shouldn't current_schema() be at least PARALLEL RESTRICTED?

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
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

In response to

Responses

Browse pgsql-hackers by date

  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?