fix: a couple of memory leaks

[imor]

No description provided.

[steve-chavez]

Comparing the memory consumption on the loadtests:

• in master: https://github.com/supabase/pg_net/actions/runs/30320037294
• this PR: https://github.com/supabase/pg_net/actions/runs/30785463316?pr=273

There doesn't seem to be a difference 🤔. So looks like there's no real "leak" here because the MemoryContext is already freeing the allocated memory?

That being said, I don't see why not do this and free the memory earlier but then this should be a refactor: commit?

@imor WDYT?

[imor]

Comparing the memory consumption on the loadtests:

• in master: https://github.com/supabase/pg_net/actions/runs/30320037294
• this PR: https://github.com/supabase/pg_net/actions/runs/30785463316?pr=273

There doesn't seem to be a difference 🤔. So looks like there's no real "leak" here because the MemoryContext is already freeing the allocated memory?

That being said, I don't see why not do this and free the memory earlier but then this should be a refactor: commit?

@imor WDYT?

Sorry I should have explained better in the description.

It is a valid leak, just not in the background worker. It's not captured in the loadtests because they look at the memory of the background worker, while the actual leak is in the backend process which calls _urlencode_string and _encode_url_with_params_array via the http_get calls. Memory context can't free this memory because it's not palloced but malloced in libcurl. For this reason I don't think this should be treated as a refactor. If you want I can try to capture the memory usage of the client backend process in loadtests but IMO it's clear enough by statically analyzing the code that this is a memory leak and a test proving it is kinda overkill.

[steve-chavez]

@imor Thanks for elaborating, I agree it's a fix.