On Sun, 26 May 2024 at 19:39, Tom Lane wrote:
> Hm, should it be? That's hard-won knowledge, and I'm not sure there
> is a good reason to believe it's no longer applicable.
Okay, so I looked into this a bit more and there's a similar case here
that's imho very clearly doing something incorrectly
On Sun, May 26, 2024, 12:26 Jelte Fennema-Nio wrote:
> DISCARD PLANS should probably forget about it though indeed.
>
DISCARD PLANS should probably **not** forget about it
> > Note that any change in behavior there would affect prepared
> > statements in general, not only plpgsql.
>
> DISCARD
ne 26. 5. 2024 v 21:27 odesÃlatel Jelte Fennema-Nio
napsal:
> On Sun, 26 May 2024 at 19:39, Tom Lane wrote:
> > Hm, should it be? That's hard-won knowledge, and I'm not sure there
> > is a good reason to believe it's no longer applicable.
>
> I think for DISCARD ALL it would probably make sense
On Sun, 26 May 2024 at 19:39, Tom Lane wrote:
> Hm, should it be? That's hard-won knowledge, and I'm not sure there
> is a good reason to believe it's no longer applicable.
I think for DISCARD ALL it would probably make sense to forget this
knowledge . Since that is advertised as "reset the sess
Jelte Fennema-Nio writes:
> I got a report on the PgBouncer repo[1] that running DISCARD ALL was
> not sufficient between connection handoffs to force replanning of
> stored procedures. Turns out that while DISCARD AL and DISCARD PLAN
> reset the plan cache they do not reset the num_custom_plans f
