Re: Is temporary functions feature official/supported? Found some issues with it.

On Thu, Jan 10, 2019 at 11:47:32AM +0900, Masahiko Sawada wrote:
> Yes, I was confused that in spite of the relation is a kind of
> database object we separate two cases, relation and database objects
> other than relation. So I thought that we can merge these flags to
> something like XACT_FLAGS_ACCESSEDTEMPOBJ tracking whether the
> transaction created, locked or dropped objects such as tables,
> functions and datatypes on a temoprary namespace.

Sure. For HEAD I don't mind doing so and that makes sense. On
back-branches though that's another story...

> I've found a corner-case issue with this patch; this issue still
> happens when we create the extension on the temprary namespace,
> because it can be done without accessing the namespace if the
> temporary namespace is already created.
>
> postgres(1:59232)=# create table pg_temp.e(c int);
> CREATE TABLE
> postgres(1:59232)=# begin;
> BEGIN
> postgres(1:59232)=# create extension pgcrypto schema pg_temp_3;
> CREATE EXTENSION
> postgres(1:59232)=# prepare transaction 'a';
> PREPARE TRANSACTION
> postgres(1:59232)=# create extension pgcrypto;
> (hang..)

There is a reason why I have split that part into a separate patch and
a separate thread:
https://commitfest.postgresql.org/22/1969/

The thing is that this behavior is rather unstable, for example I bump
easily into that:
=# create extension dblink schema pg_temp_3;
ERROR: 42883: function dblink_connect_u(text) does not exist

> Also, since even the current_schame() and the current_schemas() could
> create the temporary namespace when executing fetch_search_path()
> while 'pg_temp' appears the head of seach_patch, for example, the
> following transaction cannot prepre. But it possible could be
> acceptable by users as this is very corner case and it could be
> regards as accessing the temporary namespace actually.

Yeah, but the temporary schema gets created, which is something that
we want to avoid, so 2PC must fail on that case as well or you would
run again into the same locking hazards if the same temp schema gets
reused in a different backend.
--
Michael