From: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgstattuple "unexpected zero page" for gist and hash indexes |
Date: | 2025-10-01 15:01:48 |
Message-ID: | CAH5HC977v7n9qKZ5nGLjk4a9CXosG5mktbMTmxi6Z_qu4uYy4g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> --
> Michael
Thanks Michael. I'm attaching v3 with this change.
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Fix-unexpected-zero-page-in-pgstattuple-for-hash-.patch | application/octet-stream | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniil Davydov | 2025-10-01 15:18:06 | Re: Problem while updating a foreign table pointing to a partitioned table on foreign server |
Previous Message | Amit Kapila | 2025-10-01 14:48:22 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |