I wrote:
> Given the lack of field complaints over the many years it's been
> like this, there doesn't seem to be a live problem. I think the
> explanation for that is
> (1) those mechanisms are never used to call set-returning functions,
> (2) therefore, the tuplestore will not be called on to hold more
> than one result row,
> (3) therefore, it won't get large enough that it wants to spill
> to disk,
> (4) therefore, its potentially dangling resowner pointer is never
> used.
> However, this is an uncomfortably shaky chain of assumptions.
> I want to cut it down by fixing things so that there is no
> tuplestore, period, in a non-set-returning SQL function.
Following up on this thread: Alexander Lakhin's report at [1] shows
that point (3) above is wrong: the tuplestore code will spill to disk
even when holding just one tuple, if that tuple is bigger than the
tuplestore's allowed work_mem. (This seems kinda dubious to me, since
no memory savings can ensue. But I have no desire to rejigger that
right now.) So there may actually be a live bug associated with
use of a deleted resource owner here. I've not tried to pursue that
though.
More immediately: Alexander's report also shows that there's an easily
reached bug in HEAD when the tuplestore does spill to disk. When it
reads that tuple back in, it allocates it in the caller's memory
context, and fmgr_sql is now calling that in the short-lived context
it was called in not in its long-lived fcontext. The end result of
that is that the long-lived result TupleTableSlot is now holding a
should_free pointer to a short-lived tuple, which ends up in an
attempt to pfree already-wiped storage during the next call of the
SQL function.
The patch I presented here eliminates that problem because with it,
fmgr_sql no longer pulls tuples out of the tuplestore at all.
So I want to apply this patch now instead of holding it for v19.
regards, tom lane
[1] https://www.postgresql.org/message-id/9f975803-1a1c-4f21-b987-f572e110e860%40gmail.com
