Re: pgstattuple "unexpected zero page" for gist and hash indexes
От | Dilip Kumar |
---|---|
Тема | Re: pgstattuple "unexpected zero page" for gist and hash indexes |
Дата | |
Msg-id | CAFiTN-tZBZBhYU6MQbV_5w_6SuK2tZ_EnHnZx2vQ2s52BNskHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgstattuple "unexpected zero page" for gist and hash indexes (Nitin Motiani <nitinmotiani@google.com>) |
Ответы |
Re: pgstattuple "unexpected zero page" for gist and hash indexes
|
Список | pgsql-hackers |
On Wed, Oct 1, 2025 at 8:32 PM Nitin Motiani <nitinmotiani@google.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@paquier.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
В списке pgsql-hackers по дате отправления: