Re: Patch: plan invalidation vs stored procedures

2008/8/19 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
> On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
>> 2008/8/18 Hannu Krosing <hannu(at)2ndquadrant(dot)com>:
>> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
>> >> 2008/8/18 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
>> >> > Hi,
>> >> >
>> >> > Le lundi 18 août 2008, Andrew Dunstan a écrit :
>> >> >> > On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
>> >> >> >> This is not the kind of patch we put into stable branches.
>> >> >>
>> >> >> So what? That is not the only criterion for backpatching.
>> >> >
>> >> > I fail to understand why this problem is not qualified as a bug.
>> >> >
>> >>
>> >> Does it change of result some queries?
>> >
>> > Not in the long run, but not invalidating the functions (current
>> > behaviour) postpones seeing the results of function change until DBA
>> > manually restarts the error-producing client.
>> >
>> >> It is protection to server's hang?
>> >
>> > Can't understand this question :(
>> >
>> > If you mean, does the change protect against hanging the server, then
>> > no, currently the server does not actually hang, it just becomes
>> > unusable until reconnect :(
>>
>> Hi
>>
>> I am sorry, but it's really new feature and not bug fix
>
> Could you please explain why you think so ?
>
> As I see it, the patch does not change visible behaviour, except
> removing some sonditions where client becomes unusable after some other
> backend does some legitimate changes.

Are you sure, so this behave hasn't any secondary effect? So this
change doesn't breaks any application?

Pavel

>
> Is the current behavior planned or even defined by spec ?
>
> I agree, that the bug (if it is a bug) could also be circumvented by the
> calling function by detecting a failed cache lookup and doing
> replan/requery itself, but this would require all PL implementations and
> other functions with stored plans to do it independently.
>
> -----
> Hannu
>
>
>
>