While digging around for the cause of the buildfarm failures in the new rangetypes code, I noticed that range_gettypinfo thinks it can memcpy the result of fmgr_info(). This is not cool. It's true that fn_extra is likely to be NULL at the instant the copy occurs, but what will happen if the called function is using fn_extra is that on *each call* it will have to re-create whatever data it's caching there. That's not only bad for performance but it means a per-call memory leak.
It looks like the reason that it's done this way is that some functions call range_gettypinfo twice, presumably for types that could be different ... but if they actually were different, then again the caching would be counterproductive. I think we need to fix this so that a cached RangeTypeInfo is used in-place. The places that need two of them will need some extra code to set up a two-RangeTypeInfo cache area. Unless you see a hole in this analysis, I will go make the changes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers