Re: Proposed mid-cycle update of typedefs.list

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposed mid-cycle update of typedefs.list
Date: 2025-12-14 21:22:32
Message-ID: ybwu4m4dzsn4lqscdwycerxuj2ojhtthkqaisnjv23icqcfymj@5ny7dyhts5nz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-12-14 21:35:10 Re: Optimization of partial index creation for a new column
Previous Message Tom Lane 2025-12-14 21:14:57 Fixing out-of-range warnings with late-model gcc+UBSAN