From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Erik Wienhold <ewie(at)ewie(dot)name>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Treat <rob(at)xzilla(dot)net>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Regression with large XML data input |
Date: | 2025-07-29 14:01:19 |
Message-ID: | 6ac2f605-2caf-447c-abea-ad45b19833ab@uni-muenster.de |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29.07.25 14:11, Tom Lane wrote:
> In the original coding, there was a hazard of the node list getting
> leaked if the caller passed parsed_nodes == NULL. Or at least I
> thought there was. It may be that all releases of libxml2 are smart
> enough to free the node list if there's no way to pass it back,
> but I guess we had reason not to trust it. Possibly there's something
> about that in the discussion that led up to 6082b3d5d, though I see
> I neglected to mention it in the commit message.
I see.. thanks for explaining.
I went through the discussions and the libxml2 issue, and I also think
it is prudent to keep it like that :)
Could you add a short comment to it? Something like this:
/*
* We use a local variable (node_list) to receive the result
* from xmlParseBalancedChunkMemory(), even though we might
* eventually return it via parsed_nodes. This ensures that we
* retain control of the memory and can safely free it here
* in case of parse errors or early exits.
*
* If parsing fails, we free node_list immediately. If parsing
* succeeds, we assign it to *parsed_nodes (if provided), which
* will later be attached to the document tree. Otherwise, if
* the caller is not interested in the parsed nodes (i.e.,
* parsed_nodes == NULL), we free them immediately.
*
*/
Thanks!
Best, Jim
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-07-29 14:01:46 | Re: Adding wait events statistics |
Previous Message | Tom Lane | 2025-07-29 13:45:24 | Re: Making pgfdw_report_error statically analyzable |