Re: Regression with large XML data input

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

In response to

Responses

Browse pgsql-hackers by date

  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