Date: Tue, 13 Jun 2023 16:39:21 +0900 (JST)
Message-Id: <20230613.163921.1246444645573084901.horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: gurjeet@singh.im, ranier.vf@gmail.com, guofenglinux@gmail.com,
 pgsql-hackers@postgresql.org
Subject: Re: Avoid unncessary always true test
 (src/backend/storage/buffer/bufmgr.c)
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <ZIgIjhYW81WCTYc4@paquier.xyz>
References: <CAEudQArzX-q7FuvHxcEQKP9RuM7eFw4CnvU_xQtkiu4+tnaA4A@mail.gmail.com>
	<CABwTF4W+WMr=3bjLP5-69+oG81BEZOH+SAqPX8GDnZry5==thA@mail.gmail.com>
	<ZIgIjhYW81WCTYc4@paquier.xyz>
User-Agent: Mew version 6.8 on Emacs 27.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20230613.163921.1246444645573084901.horikyota.ntt%40gmail.com>
Precedence: bulk

At Tue, 13 Jun 2023 15:11:26 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Mon, Jun 12, 2023 at 10:51:24PM -0700, Gurjeet Singh wrote:
> > To me, it looks like these checks are a result of code being
> > copy-pasted from somewhere else, where this check might have been
> > necessary. The checks are sure not necessary at these spots.
> 
> I am not completely sure based on my read of the code, but isn't this
> check needed to avoid some kind of race condition with a concurrent
> backend may have worked on the relation when attempting to get the
> lock?

Gurjeet has mentioned that eb.rel cannot be modified by another
process since the value or memory is in the local stack, and I believe
he's correct.

If the pointed Relation had been blown out, eb.rel would be left
dangling, not nullified. However, I don't believe this situation
happens (or it shouldn't happen) as the entire relation should already
be locked.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center