Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update typedefs.list to match what the buildfarm currently reports.

  2. Make "pgoff_t" be a typedef not a #define.

  1. Proposed mid-cycle update of typedefs.list

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-14T19:57:48Z

    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?

Anyway, I'll gladly take this outcome.  I propose applying the
attached to sync the in-tree typedefs list with what the
buildfarm is currently reporting.

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.

			regards, tom lane

  2. Re: Proposed mid-cycle update of typedefs.list

    Andres Freund <andres@anarazel.de> — 2025-12-14T21:22:32Z

    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

  3. Re: Proposed mid-cycle update of typedefs.list

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-14T21:38:59Z

    Andres Freund <andres@anarazel.de> writes:
> On 2025-12-14 14:57:48 -0500, Tom Lane wrote:
>> 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:

Guess it must be.  I had thought that our tooling captures types
that are used to declare variables or fields of struct variables,
but evidently that's not the whole story.  One thing we do know
for sure is that "sizeof(footype)" does not create a capturable
reference to footype.  But maybe references within casts do?

>> 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.

I'll go deal with these things shortly.

			regards, tom lane

  4. Re: Proposed mid-cycle update of typedefs.list

    Michael Paquier <michael@paquier.xyz> — 2025-12-15T01:17:45Z

    On Sun, Dec 14, 2025 at 04:38:59PM -0500, Tom Lane wrote:
> I'll go deal with these things shortly.

Thanks for cleaning up all that!
--
Michael