Re: [PATCH] Remove twice assignment with var pageop (nbtree.c). - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Remove twice assignment with var pageop (nbtree.c).
Date
Msg-id 404.1576770942@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Remove twice assignment with var pageop (nbtree.c).  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [PATCH] Remove twice assignment with var pageop (nbtree.c).  (Bruce Momjian <bruce@momjian.us>)
Re: [PATCH] Remove twice assignment with var pageop (nbtree.c).  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Tue, Nov 26, 2019 at 01:45:10PM +0000, Ranier Vilela wrote:
>> Same case on nbtpage.c at line 1637, with var opaque.
>> make check, passed all 195 tests here with all commits.

> You were right about both of these, so removed in master.  I am
> surprised no one else saw this before.

I don't think this is actually a good idea.  What it is is a foot-gun,
because if anyone adds code there that wants to access the special area
of that particular page, it'll do the wrong thing, unless they remember
to put back the assignment of "opaque".  The sequence of BufferGetPage()
and PageGetSpecialPointer() is a very standard switch-our-attention-
to-another-page locution in nbtree and other index AMs.

Any optimizing compiler will delete the dead store, we do not have
to do it by hand.

Let me put it this way: if we had the BufferGetPage() and
PageGetSpecialPointer() calls wrapped up as an "access new page" macro,
would we undo that in order to make this code change?  We would not.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size