| From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | n(dot)kalinin(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition |
| Date: | 2026-06-09 04:38:58 |
| Message-ID: | CAE9k0PkEXWPeymZg8YmB-4_NKo3tVW3fQS-LLaWEAqstrDu9qQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Jun 5, 2026 at 9:08 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Sat, Jun 6, 2026 at 12:29 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> > pg_buffercache_pages uses RETURNS SETOF RECORD whereas other
> > extensions like pgstattuple define explicit IN/OUT parameters at the
> > SQL level. Is there a specific reason this pattern was kept, or is it
> > simply a legacy design that hasn't been modernized? Had we followed
> > the IN/OUT parameter style, this sort of issue could have been
> > avoided, no?
>
> Probably yes. But if we do that, we would likely need to bump pg_buffercache
> version. I'm not sure that's worthwhile just for this change.
>
Okay, that makes perfect sense, thanks for the confirmation.
--
With Regards,
Ashutosh Sharma.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-06-09 15:10:42 | Re: BUG #19484: Segmentation fault triggered by FDW |
| Previous Message | Fujii Masao | 2026-06-08 23:44:50 | Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition |