On Thu, Jan 17, 2019 at 9:46 PM Michael Paquier <mich...@paquier.xyz> wrote: > While working on the recent issues with 2PC and temporary objects I > have added a test case based on current_schema() for the first time in > history, and the buildfarm complained about it, as mentioned here: > https://www.postgresql.org/message-id/20190118005949.gd1...@paquier.xyz > > The has been causing crake and lapwing to complain about > current_schema() failing to create a temporary schema, which can > happen when invoked for the first time of a session: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2019-01-18%2000%3A34%3A20 > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2019-01-18%2001%3A20%3A01 > > 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 > > current_schemas() also has this problem. > > For now I have stabilized the test by making sure that non-parallel > plans get used, which makes the buildfarm happy, still that's just a > workaround in my opinion. One of the reasons why current_schema() > can create temporary schemas is that there are string dependencies > with search_path and the way sessions use it, hence it seems to me > that it would be better to mark the function at least parallel > restricted on HEAD and avoid any unstable behavior?
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
