Re: Is temporary functions feature official/supported? Found some issues with it. - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Is temporary functions feature official/supported? Found some issues with it.
Date
Msg-id 9176.1546613679@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is temporary functions feature official/supported? Found someissues with it.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Is temporary functions feature official/supported? Found someissues with it.  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jan 02, 2019 at 05:18:08PM -0500, Tom Lane wrote:
>> Hm.  I can reproduce this if I start in a virgin database, but not
>> otherwise.  I think the problem is that the prepared transaction has
>> created the pg_temp_NN schema for its session, and therefore there
>> is an uncommitted pg_namespace entry for that schema name, and the
>> second session is also trying to create that schema (because it has
>> the same backend ID) so it blocks waiting to see if that index
>> entry commits.

> That should not be allowed to commit directly.  I think that we should
> just add a new value for MyXactFlags which tracks the transaction
> where the temporary namespace has been created, and generate an error
> if trying to use 2PC in this case.  A separate flag looks necessary to
> me so as we don't bump on "cannot PREPARE a transaction that has
> operated on temporary tables" in this case.

Hm, I had forgotten that we had such an error message.  Really that
restriction needs to apply to any object in the temp namespace, not only
tables.

            regards, tom lane


pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: BUG #15555: Syntax errors when using the COMMENT command inplpgsql and a "comment" variable
Next
From: Fabrice LEGROS
Date:
Subject: SELECT do not return all rows depending on selected columns