Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ranier(dot)vf(at)gmail(dot)com
Cc: gurjeet(at)singh(dot)im, guofenglinux(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)
Date: 2023-06-14 01:01:59
Message-ID: 20230614.100159.450192360046344001.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 13 Jun 2023 08:21:20 -0300, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote in
> Em ter., 13 de jun. de 2023 às 02:51, Gurjeet Singh <gurjeet(at)singh(dot)im>
> escreveu:
>
> > Please see attached v2 of the patch; it includes both occurrences of
> > the spurious checks identified in this thread.
> >
> +1
> LGTM.

> LockRelationForExtension(eb.rel, ExclusiveLock);
>
> - /* could have been closed while waiting for lock */
> - if (eb.rel)
> - eb.smgr = RelationGetSmgr(eb.rel);
> + eb.smgr = RelationGetSmgr(eb.rel);

(It seems to me) The removed comment does refer to smgr, so we could
consider keeping it. There are places instances where the function
calls are accompanied by similar comments and others where they
aren't. However, personally, I inclined towards its removal. That's
because our policy is to call RelationGetSmgr() each time before using
smgr, and this is well documented in the function's comment.

If we decide to remove it, the preceding blank line seems to be a
separator from the previous function call. So, we might want to
consider removing that blank line, too.

Otherwise it LGTM.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-06-14 01:03:24 Re: [PATCH] Using named captures in Catalog::ParseHeader()
Previous Message Thomas Munro 2023-06-14 00:58:37 Re: Inconsistent results with libc sorting on Windows