Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: ranier(dot)vf(at)gmail(dot)com, mahi6run(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Date: 2021-08-18 08:29:58
Message-ID: 20210818.172958.24378508451846000.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote:
> > Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor <
> > mahi6run(at)gmail(dot)com> escreveu:
> >> Please can we try to hit this rare condition by any test case. If you have
> >> any test cases, please share.
>
> Yeah, this needs to be proved. Are you sure that this change is
> actually right? The bottom of FreePageManagerPutInternal() has
> assumptions that a page may not be found during a btree search, with
> an index value used.

By a quick look, FreePageBtreeSearch is called only from
FreePageManagerPutInternal at three points. The first one assumes that
result.found == true, at the rest points are passed only when
fpm->btree_depth > 0, i.e, fpm->btree_root is non-NULL.

In short FreePageBtreeSeach is never called when fpm->btree_root is
NULL. I don't think we need to fill-in other members since the
contract of the function looks fine.

It might be simpler to turn 'if (btp == NULL)' to an assertion.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-08-18 08:39:08 Re: Skipping logical replication transactions on subscriber side
Previous Message Denis Hirn 2021-08-18 08:28:06 Re: [PATCH] Allow multiple recursive self-references