| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, zlh21343(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Subject: | Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions = |
| Date: | 2026-06-20 22:51:25 |
| Message-ID: | ajcZbT3S7yuDDMl4@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sat, Jun 20, 2026 at 06:58:27PM +0200, Alvaro Herrera wrote:
> Yeah, this sounds more or less reasonable. The callers that pass
> missing_ok=false could still use the original function name though, no?
>
> (Personally I would do for an ABI compatibility in back branches with
> this new function, and an API breakage in master by simply adding the
> new argument everywhere, but keeping the old function name. This way we
> don't preserve unnecessary API ugliness forever.)
Yes, that would be the idea:
- On HEAD, keep the old function name, add the parameter.
- On the back-branches, use the new function name with the new
parameter. And contrary to you limit the use of the old function
name.
Using the old function name in the back-branches where missing_ok is
false would also work, of course. My suggestion just makes one less
call showing up on the stack. The previous patch posted is not for
HEAD, only for v15~v18.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-06-21 05:47:33 | Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table |
| Previous Message | Laurenz Albe | 2026-06-20 21:53:01 | Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table |