public inbox for [email protected]  

help / color / mirror / Atom feed

From: Ayush Tiwari <[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 09:12:20 +0530
Message-ID: <CAJTYsWX6b0UxeZ9HGGnju-XpWRmLr_y8AVeyWqd3gL+a0NkGtw@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,

On Fri, 5 Jun 2026 at 08:49, Fujii Masao <[email protected]> wrote:

>
> 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?
>

Thanks for the patch, Fujii-san!

I was looking into the bug last night, and the approach looks right to me.

This still means InitMaterializedSRF() briefly creates the caller-derived
descriptor before rsinfo->setDesc is replaced. That seems acceptable here:
the descriptor lives only in the per-query context, and avoiding a local
copy of InitMaterializedSRF() keeps the fix much smaller and less fragile.

One small nit: build_buffercache_pages_tupledesc() names attribute 8
"usage_count", while the existing pg_buffercache view and the test use
"usagecount". This probably does not affect the tupledesc_match() check,
but I think it would be better to keep the existing spelling for
consistency.

Regards,
Ayush

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: <CAJTYsWX6b0UxeZ9HGGnju-XpWRmLr_y8AVeyWqd3gL+a0NkGtw@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