On Sun, Dec 17, 2017 at 10:40 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Dec 14, 2017 at 5:58 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>> The ambiguity about who owns the tuple memory when is the basic
>> problem, once again. One could argue that it's the caller's fault for
>> not knowing to not pfree() the tuple after tuplesort_end() is called,
>> but I don't buy that because it seems like an undue burden on callers
>> to do that. It seems okay to either provide a very weak, simple
>> guarantee about tuple memory lifetime, or very strong simple guarantee
>> about tuple memory lifetime. That's what routines like
>> tuplesort_gettupleslot() and tuplesort_getindextuple() should limit
>> their contracts to -- we've had enough problems in this area over the
>> years that that seems pretty clear to me.
>>
>> ISTM that an appropriate fix is one that results in having
>> tuplesort_gettupleslot() tuple memory that is *consistently* allocated
>> within caller's own memory context, at least on versions prior to
>> Postgres 10 (it's a bit more complicated in Postgres 10).
>
> This took longer than expected. Attached patch, which targets 9.6,
> shows what I have in mind. I'm going on vacation shortly, but wanted
> to post this patch before I leave. It could definitely use some more
> testing, since it was written under time pressure. I expect to be back
> early in the new year, so if someone feels like taking this off my
> hands, they're more than welcome to do so.
Could you add that to the next commit fest registered as a bug fix? We
don't want to lose track of that and this should be reviewed.
--
Michael
