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
|
Список | 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 по дате отправления: