From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: jsonapi: scary new warnings with LTO enabled |
Date: | 2025-04-16 23:04:50 |
Message-ID: | 2084687.1744844690@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 17 Apr 2025, at 00:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The only alternative I can see that might stop the warning is if we
>> can find a way to make it clearer to the optimizer that the FREE()
>> isn't reached. But I'm not sure about a trustworthy way to make that
>> happen.
> Yeah, that seems messy enough that someone down the line will go "why on earth"
> and we'll have to revisit this discussion. It can probably be made to work but
> I doubt it will be worth it compared to allocating on the heap.
Looking through all of the callers of freeJsonLexContext, quite
a lot of them use local JsonLexContext structs, and probably some
of them are more performance-critical than these. So that raises
the question of why are we seeing warnings for only these call
sites? Maybe there is a more elegant way to suppress them.
Still, I think that observation refutes my initial thought that
we should rip out support for local JsonLexContext structs
altogether. I'm inclined now to just do the minimal thing of
changing these callers to use an allocated struct, and call it
a day. (BTW, there seem to be only 2 places to change not 3;
two of the warnings are pointing at the same variable.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-04-16 23:09:40 | Re: jsonapi: scary new warnings with LTO enabled |
Previous Message | David Rowley | 2025-04-16 22:31:57 | Re: Align memory context level numbering in pg_log_backend_memory_contexts() |