| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, Bruce Momjian <bruce(at)momjian(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Subject: | Re: Performance issues with v18 SQL-language-function changes |
| Date: | 2025-05-01 14:19:06 |
| Message-ID: | 1600725.1746109146@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Hmm. What seems to be going on here is that once the aggfns_trans()
> result gets large enough that the SQL-function-result tuplestore
> decides to spill to disk, when we pull the result tuple back out
> of the tuplestore with tuplestore_gettupleslot we end up with the
> jf_resultSlot holding a should-free tuple pointer that points into
> the tuplestore's storage. After tuplestore_clear that is a dangling
> pointer, and the next use of the jf_resultSlot fails while trying to
> free the tuple.
I still haven't figured out why this wasn't a problem in the old
version of functions.c. However, I did realize that my pending
patch at [1] gets rid of the problem in another way, by removing
functions.c's use of tuplestore_gettupleslot altogether. Now
I'm tempted to just push that, instead of applying a band-aid that
will leave v18 doing this differently from both earlier and later
branches.
regards, tom lane
[1] https://www.postgresql.org/message-id/2443532.1744919968%40sss.pgh.pa.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2025-05-01 14:31:28 | Re: RFC: Additional Directory for Extensions |
| Previous Message | Nathan Bossart | 2025-05-01 14:14:50 | Re: Should shared_preload_libraries be loaded during binary upgrade? |