Date: Fri, 18 Jan 2019 09:59:49 +0900
From: Michael Paquier <michael@paquier.xyz>
To: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Restrict the use of temporary namespace in two-phase
 transaction
Message-ID: <20190118005949.GD1883@paquier.xyz>
References: <E1gkHvw-00010c-3O@gemulon.postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg"
Content-Disposition: inline
In-Reply-To: <E1gkHvw-00010c-3O@gemulon.postgresql.org>
Precedence: bulk


--C1iGAkRnbeBonpVg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 18, 2019 at 12:22:52AM +0000, Michael Paquier wrote:
> Restrict the use of temporary namespace in two-phase transactions
>=20
> 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=3Dcrake&br=3DHE=
AD

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 namesp=
ace

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 =3D 0;
SET max_parallel_workers_per_gather =3D 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

--C1iGAkRnbeBonpVg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlxBJQUACgkQnvQgOdby
QH3wYxAApcrWNo/SM1bQHJqykS2hm+1U4Nx0i9IdFiEXfYiaAWAvj5+Zvh9EG8wu
epPurQhJM8V554xgF0EYvM6bcAmS9yfhTBkh2YZPlrK3ND28qI1bB3j1RylWHb8M
hb7fefSXULRDfq1oJ0gE6SidAkKLGRrAkcwB+Zni9s212qdnJmInxSaMmCnMvgiO
oZJp++YQOnVAEWQmIBfTHm+2AT63VIe92uH7eQU5/9k8KcdMBPM61OrU23dsfQCD
8ltQ4eB4mZXM30Ib7h3Py6JRgw4zxM1Vs1/Suq9HUho2zkC8SvHhWQzRELtanM+R
rFsQ0mCCQ+b71NS8QapYyqiTnPR+tg6JAEmOJlrduMhllwjUR/6tU2vR8/dXUA0t
tkkCx3M92tIfySH2cTjtYKUPgwVXoFV0DRVeWx0Ud6o1kgqWx7supQjck38r3cX1
lhNXzYsigfCMlt7rtvOLtNdbhKjWUvFN33JSkladRdnR+tcSq8TZE47J1wSIeZnT
4zdZalH48iGrA97Xmg8yUiE6ZIiuI8zXkP0ROvqIwEqYTNbpcVLTIfss4b3W1MRn
uI2Lk81Zg+DdwTj+h178IISdQVysyhQ0iRaKyZDJ2giAiPUwuqL3obC7w2y/fW6T
5E+dx8GKY2BFoyYw5bjGSIgji7i+e+bA9JWk6Pw0GRE/k0savRc=
=Zgkf
-----END PGP SIGNATURE-----

--C1iGAkRnbeBonpVg--