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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, pgsql-bugs <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-09 07:30:11
Message-ID: 20190109073011.GB23045@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jan 09, 2019 at 04:00:51PM +0900, Masahiko Sawada wrote:
> /*
> * XACT_FLAGS_ACCESSEDTEMPREL - set when a temporary relation is accessed. We
> * don't allow PREPARE TRANSACTION in that case.
> */
> #define XACT_FLAGS_ACCESSEDTEMPREL (1U << 0)
> (snip)
> +/*
> + * XACT_FLAGS_ACCESSEDTEMPNAMESPACE - set when a temporary namespace is
> + * accessed. We don't allow PREPARE TRANSACTION in that case.
> + */
> +#define XACT_FLAGS_ACCESSEDTEMPNAMESPACE (1U << 2)
>
> The cases where we set XACT_FLAGS_ACCESSEDTEMPNAMESPACE seems to
> include the cases setting XACT_FLAGS_ACCESSEDTEMPREL. Is there any
> path where we access a temporary relation without accessing temporary
> namespace?

This case would set ACCESSEDTEMPREL but not ACCESSEDTEMPNAMESPACE:
create temp table twophase_tab (a int);
begin;
select a from twophase_tab;
prepare transaction 'twophase_tab';

I kept the original flag mainly for compatibility with the past
handling so as the error message remains constant and back-patchable
for application relying on the existing behavior. I think that for
HEAD we could consider moving on with an approach where we have only
ACCESSEDTEMPNAMESPACE, still we may want to make a difference for
transactions which have actually tried to take any kind of locks on
the temporary relation.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bartosz Polnik 2019-01-09 07:48:43 Re: BUG #15577: Query returns different results when executed multiple times
Previous Message Michael Paquier 2019-01-09 07:14:11 Re: BUG #15567: Wal receiver process restart failed when a damaged wal record arrived at standby.