Re: pgstattuple "unexpected zero page" for gist and hash indexes

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Nitin Motiani <nitinmotiani(at)google(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgstattuple "unexpected zero page" for gist and hash indexes
Date: 2025-10-01 15:23:01
Message-ID: CAFiTN-tZBZBhYU6MQbV_5w_6SuK2tZ_EnHnZx2vQ2s52BNskHg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 1, 2025 at 8:32 PM Nitin Motiani <nitinmotiani(at)google(dot)com> wrote:
>
> Apologies, I accidentally sent my previous reply only to Michael
> instead of hitting 'reply all'. Adding the contents of those messages
> in the quoted text.
>
> On Wed, Oct 1, 2025 at 4:45 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> > On Wed, Oct 01, 2025 at 04:17:49PM +0530, Nitin Motiani wrote:
> > > Thanks Michael. We can keep the simple change we have in v2 without
> > > reporting any corruption. But perhaps we should check for the opaque
> > > size mismatch for btree (as it's already done for gist and hash) to
> > > keep the code consistent for all three. We can avoid any reporting or
> > > further analysis but we can skip the other operations in the case of
> > > size mismatch. What are your thoughts on that?
> >
> > You mean an check on BTPageOpaqueData with a new else branch in
> > pgstat_btree_page()? Yep, let's do that as well.
> > --
>
> Thanks Michael. I'm attaching v3 with this change.

I think this looks good to me now, lets see what Michael has to say on
this, after that we can mark ready for committer.

--
Regards,
Dilip Kumar
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Frits Hoogland 2025-10-01 15:25:00 Re: The ability of postgres to determine loss of files of the main fork
Previous Message Peter Eisentraut 2025-10-01 15:19:56 Re: _CRT_glob stuff