Skip to content

Commit 0510e24

Browse files
committed
Comment on memory
1 parent 04761dd commit 0510e24

1 file changed

Lines changed: 12 additions & 1 deletion

File tree

http.c

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -251,6 +251,17 @@ http_progress_callback(void *clientp, curl_off_t dltotal, curl_off_t dlnow, curl
251251

252252
#endif /* 7.39.0 */
253253

254+
/*
255+
* In theory bringing memory handling inside the PgSQL
256+
* memory manager makes sense, but in practice the lifecycle
257+
* PgSQL is using is out of sync with the one curl is
258+
* using, so PgSQL might free a block of memory out
259+
* from under curl. If connection persistence was
260+
* removed, it would be possible to do this where curl
261+
* was entirely setup/connect/disconnect/shutdown
262+
* within a single function call. As it currently
263+
* stands, enabling this just causes crashes.
264+
*/
254265
#undef HTTP_MEM_CALLBACKS
255266
#ifdef HTTP_MEM_CALLBACKS
256267
static void *
@@ -1689,7 +1700,7 @@ Datum urlencode_jsonb(PG_FUNCTION_ARGS)
16891700
k.type = jbvString;
16901701
k.val.string.val = key;
16911702
k.val.string.len = strlen(key);
1692-
v = *findJsonbValueFromContainer(&jb->root, JB_FOBJECT, &k);
1703+
v = *findJsonbValueFromContainer(&jb->root, JB_FOBJECT, &k);
16931704
}
16941705
#else
16951706
getKeyJsonValueFromContainer(&jb->root, key, strlen(key), &v);

0 commit comments

Comments
 (0)