On Tue, 2008-08-19 at 12:42 +0200, Pavel Stehule wrote:
> 2008/8/19 Hannu Krosing <hannu@2ndquadrant.com>:
> > On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
> >> 2008/8/18 Hannu Krosing <hannu@2ndquadrant.com>:
> >> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
> >> >> 2008/8/18 Dimitri Fontaine <dfontaine@hi-media.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?
I can't think of any.
What it does, is it makes the changed function usable right after
redefining the new function.
Current behaviour is to make the calling function unusable until the
backend is restarted, after which it still will use the new version of
the function.
> 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
> >
> >
> >
> >
>
