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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, pgsql-bugs(at)postgresql(dot)org, mmitar(at)gmail(dot)com
Subject: Re: Is temporary functions feature official/supported? Found some issues with it.
Date: 2019-01-07 02:42:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

On Sat, Jan 05, 2019 at 09:00:37AM +0900, Michael Paquier wrote:
> I think I can get that worked out with a back-patchable approach,
> still it looks a bit sensitive because of the creation-pending logic
> which relies on the assertion at the top of InitTempTableNamespace,
> which is a case we may want to handle with an extra flag for the
> caller of InitTempTableNamespace(), aka "fail if myTempNamespace is
> valid instead of just returning back".

Looking at this stuff, I have been able to come up with the attached,
which introduces a new flag mode for MyXactFlags, which gets set in a
couple of code paths so as PREPARE TRANSACTIOn complains:
- When attempting a LOCK on a temporary relation.
- When dropping objects part of a temporary namespace.
- When trying to access the temporary schema of a session, where it
may be initialized (or not if already present).

I have added test cases for things I could come up with, particularly
the LOCK and DROP cases which I have thought about after hacking the
code. I think that something among those lines should be


Attachment Content-Type Size
temp-object-2pc.patch text/x-diff 12.8 KB

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-01-07 03:52:26 BUG #15578: Executing json_populate_recordset with an empty array causes a segmentation fault
Previous Message David Rowley 2019-01-07 01:57:25 Re: BUG #15577: Query returns different results when executed multiple times