Re: Proposed mid-cycle update of typedefs.list

Hi,

On 2025-12-14 14:57:48 -0500, Tom Lane wrote:
> I happened to notice that the buildfarm's current typedefs list
> adds quite a few names that were not previously being captured,
> for example
> 
> @@ -48,10 +48,15 @@ AggPath
>  AggSplit
>  AggState
>  AggStatePerAgg
> +AggStatePerAggData
>  AggStatePerGroup
> +AggStatePerGroupData
>  AggStatePerHash
> +AggStatePerHashData
>  AggStatePerPhase
> +AggStatePerPhaseData
>  AggStatePerTrans
> +AggStatePerTransData
>  AggStrategy
>  AggTransInfo
>  Aggref
> 
> This is great, because it means that the declarations of these
> structs need not look funny anymore.  But I am not quite sure why
> this happened.  It's not a BF tooling change as I first thought,
> because multiple animals are reporting these names and the
> same animals are not capturing these names on the back branches.
> The best theory I can come up with is that 1b105f947 et al
> used these names in palloc0_array and similar calls, and that
> somehow looks like a capturable typedef reference ... but how?

That's indeed curious. I wonder if it's because the return type is cast
differently:

Before:
    peraggs = (AggStatePerAgg) palloc0(sizeof(AggStatePerAggData) * numaggs);
after
    peraggs = palloc0_array(AggStatePerAggData, numaggs);
where palloc_array() will transform that to

    peraggs = (AggStatePerAggData*) palloc(sizeof(AggStatePerAggData) * numaggs);

note that the return type is cast to AggStatePerAggData instead of
AggStatePerAgg.  Other than the sizeof() there previously were no references
to AggStatePerAggData. But I guess the intermediary of type
AggStatePerAggData* now leads to it being in the debug info.


LGTM.


> One change I did not apply is that the buildfarm's list omits pgoff_t,
> although we certainly still use that.  This is evidently because
> pgoff_t is defined as a macro not a typedef name.  I guess we've been
> manually preserving that name in the list, but it seems like we should
> change "#define pgoff_t off_t" to "typedef off_t pgoff_t;" to avoid
> that manual hack.  I've not done that here, though.

Sounds like a good idea to me.


Greetings,

Andres Freund