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.
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
