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
