Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition

On Fri, Jun 5, 2026 at 12:49 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 19508
> Logged by: Nikita Kalinin
> Email address: n(dot)kalinin(at)postgrespro(dot)ru
> 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 <heikki(dot)linnakangas(at)iki(dot)fi>
> 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?

Regards,

--
Fujii Masao