Re: Assertion failure from plan cache invalidation

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Assertion failure from plan cache invalidation
Date: 2010-08-13 15:21:38
Message-ID: 4C656302.3030201@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 13/08/10 18:18, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> PushOverrideSearchPath() assumes that if the temporary namespace existed
>> when an override search path was memorized with GetOverrideSearchPath(),
>> it must still exist. That's not true in the above example, rolling back
>> the transaction that the temporary namespace was created in drops it.
>
> Hm ... seems like there are two possibilities here. We could forcibly
> recreate the temp schema, or we could just ignore the useTemp flag.

Yeah, I was undecided on that too.

> The former would more nearly approximate the situation that prevailed
> at GetOverrideSearchPath() time, but on the other hand it's not clear
> that it's a good idea for PushOverrideSearchPath() to have side-effects
> like that. I *think* that it'd be safe, at least for the two existing
> callers, but ...
>
> In the plancache case it could be argued that there's no real reason
> to recreate the temp schema: it would necessarily be empty, so it
> couldn't affect the results of planning anyhow. So the second solution
> would work just fine for the current usage.
>
> Thoughts?

Let's do the latter, add a comment noting that, and extend it later if
necessary.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-08-13 15:26:44 Re: Assertion failure from plan cache invalidation
Previous Message Tom Lane 2010-08-13 15:18:48 Re: Assertion failure from plan cache invalidation