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 |
Message-ID: | 20190107024211.GA22498@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
back-patched.
Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
temp-object-2pc.patch | text/x-diff | 12.8 KB |
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 |