Re: Plan cache and name space behavior in 9.2
От | Hitoshi Harada |
---|---|
Тема | Re: Plan cache and name space behavior in 9.2 |
Дата | |
Msg-id | CAP7QgmnKMw0XK_wRynA1i_bi++S6hqGKH6od6NbAMHy-DFyU7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Plan cache and name space behavior in 9.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Sep 14, 2012 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hitoshi Harada <umi.tanuki@gmail.com> writes: >> I expected success in tname::regclass in the function chck(), but it >> actually fails for your first run in the session. > > Really? Not for me. > > In the example as given, I see success for "call 1" and then an error at > "call 2", which is occurring because we're trying to replan the query > with the original search_path, which doesn't include the temp schema > since it didn't exist yet. I'm saying the same thing actually. I see success for call 1 and error at call 2, which was not observed in 9.1 and older. > A replan would have failed in previous versions too, but that's much > less likely in previous versions since you'd need to see a relcache > invalidation on one of the referenced tables to make one happen. I don't think so. I tried it in 9.1 and succeeded. I found this during the test of an external module that has been running back to 8.4. So I wonder if we could say this is a behavior change or a bug. And I agree the replan failure would be sane if the function was marked as immutable or stable, but all the functions I defined in the example is volatile. I'm not sure how others feel, but at least it's surprising to me that the call 2 keeps the state of call 1 though it is a volatile function. I have not been tracking the periodic discussion of plan cache vs search_path, but what is the beneficial use case of the new behavior? Thanks, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: