public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Sharma <[email protected]>
To: Fujii Masao <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition
Date: Fri, 5 Jun 2026 20:59:23 +0530
Message-ID: <CAE9k0Pkr+KKSx4UVmrLp-ZgF1BtwoVCOHOL99MeXr81D8JnX1w@mail.gmail.com> (raw)
In-Reply-To: <CAHGQGwGaC8RNeVP3A4_R1OcHJ-DrXgr2HH2UEYrt-Ueu516Gng@mail.gmail.com>
References: <[email protected]>
<CAHGQGwGaC8RNeVP3A4_R1OcHJ-DrXgr2HH2UEYrt-Ueu516Gng@mail.gmail.com>
Hi Fujii-san,
On Fri, Jun 5, 2026 at 8:49 AM Fujii Masao <[email protected]> wrote:
>
> On Fri, Jun 5, 2026 at 12:49 AM PG Bug reporting form
> <[email protected]> wrote:
> >
> > The following bug has been logged on the website:
> >
> > Bug reference: 19508
> > Logged by: Nikita Kalinin
> > Email address: [email protected]
> > PostgreSQL version: 19beta1
> > Operating system: Fedora 44
> > Description:
> >
> > Hello,
> >
> > It appears that pg_buffercache_pages() trusts a caller-supplied record
> > descriptor without verifying that the declared column types match the actual
> > values returned by the function.
> >
> > The crash is reproducible on the current master branch with a fresh cluster
> > after installing the extension:
>
> Thanks for the report! I could reproduce this as well.
>
>
> > git blame points to the following commit:
> >
> > commit 257c8231bf97a77378f6fedb826b1243f0a41612 (HEAD)
> > Author: Heikki Linnakangas <[email protected]>
> > Date: Tue Apr 7 16:04:48 2026 +0300
> >
> > Modernize and optimize pg_buffercache_pages()
>
> Commit 257c8231bf9 changed pg_buffercache_pages() to materialize rows directly
> into a tuplestore. As a result, the function started using the caller-supplied
> RECORD descriptor as rsinfo->setDesc, so a mismatched column definition list
> could cause tuplestore_putvalues() to interpret returned Datums with incorrect
> types.
>
> Before that change, pg_buffercache_pages() exposed its actual tuple descriptor
> to the executor, allowing the executor's existing rowtype checks to reject
> incompatible definitions with a normal error.
>
> The attached patch restores that behavior while keeping the materialized-SRF
> implementation. Thoughts?
>
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?
--
With Regards,
Ashutosh Sharma.
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition
In-Reply-To: <CAE9k0Pkr+KKSx4UVmrLp-ZgF1BtwoVCOHOL99MeXr81D8JnX1w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox