On 01/04/2012 06:15 PM, David E. Wheeler wrote:
[11:12pm]TonyC:theory: using sv_mortalcopy() instead of newSVsv() should prevent the leak in that workaround, assuming there's no FREETMPS between the call and use of the return value
That's the solution to leakiness I had in mind. Tom said:
2. A slightly cleaner fix for this should be to duplicate the SV and then release the copy around the SvPVutf8 call, only if it's readonly. "Fixing" it in do_util_elog is entirely the wrong thing.
How do we tell if it's readonly? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
