Re: pgsql: Restrict the use of temporary namespace in two-phasetransaction

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pgsql: Restrict the use of temporary namespace in two-phasetransaction
Дата
Msg-id 20190118005949.GD1883@paquier.xyz
обсуждение исходный текст
Ответ на pgsql: Restrict the use of temporary namespace in two-phasetransaction  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pgsql: Restrict the use of temporary namespace in two-phase transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-committers
On Fri, Jan 18, 2019 at 12:22:52AM +0000, Michael Paquier wrote:
> Restrict the use of temporary namespace in two-phase transactions
>
> Attempting to use a temporary table within a two-phase transaction is
> forbidden for ages.  However, there have been uncovered grounds for
> a couple of other object types and commands which work on temporary
> objects with two-phase commit.  In short, trying to create, lock or drop
> an object on a temporary schema should not be authorized within a
> two-phase transaction, as it would cause its state to create
> dependencies with other sessions, causing all sorts of side effects with
> the existing session or other sessions spawned later on trying to use
> the same temporary schema name.

I have been monitoring the buildfarm and crake is complaining:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=crake&br=HEAD

Here is the problem:
SET search_path TO 'pg_temp';
BEGIN;
SELECT current_schema() ~ 'pg_temp' AS is_temp_schema;
- is_temp_schema
-----------------
- t
-(1 row)
-
+ERROR:  cannot create temporary tables during a parallel operation
PREPARE TRANSACTION 'twophase_search';
-ERROR:  cannot PREPARE a transaction that has operated on temporary namespace

I am actually amazed to see the planner choose a parallel plan for
that, and the test can be fixed by enforcing those parameters I think:
SET max_parallel_workers = 0;
SET max_parallel_workers_per_gather = 0;
Could somebody confirm my assumption here by the way?  This enforces a
non-parallel plan, right?

Anyway, it seems to me that this is pointing out to another issue:
current_schema() can trigger a namespace creation, hence shouldn't we
mark it as PARALLEL UNSAFE and make sure that we never run into this
problem?
--
Michael

Вложения

В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Avoid assuming that we know the spelling of getopt_long'serror
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Restrict the use of temporary namespace in two-phase transaction