Re: Simplify newNode()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplify newNode()
Date: 2023-12-14 08:32:09
Message-ID: b5c2d75f-f871-4dae-a0e2-b35c4da0ca2c@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.12.23 01:48, Heikki Linnakangas wrote:
> The newNode() macro can be turned into a static inline function, which
> makes it a lot simpler. See attached. This was not possible when the
> macro was originally written, as we didn't require compiler to have
> static inline support, but nowadays we do.
>
> This was last discussed in 2008, see discussion at
> https://www.postgresql.org/message-id/26133.1220037409%40sss.pgh.pa.us.
> In those tests, Tom observed that gcc refused to inline the static
> inline function. That was weird, the function is very small and doesn't
> do anything special. Whatever the problem was, I think we can dismiss it
> with modern compilers. It does get inlined on gcc 12 and clang 14 that I
> have installed.

I notice that the existing comments point out that the size argument
should be a compile-time constant, but that is no longer the case for
ExtensibleNode(). Also, newNode() is the only caller of palloc0fast(),
which also points out that the size argument should be a compile-time
constant, and palloc0fast() is the only caller of MemSetTest(). I can
see how an older compiler might have gotten too confused by all that.
But if we think that compilers are now smart enough, maybe we can unwind
this whole stack a bit more? Maybe we don't need MemSetTest() and/or
palloc0fast() and/or newNode() at all?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-12-14 08:38:40 Re: GUC names in messages
Previous Message Dilip Kumar 2023-12-14 08:23:12 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock