Re: BUG #18950: pgsql function that worked in Postgresql 16 does not return in Postgresql 17

Changing that parameter had no effect on the version 17 instance. The
query itself produces results in a matter of a second or so, but the
function still hangs and does not return.

Lowell

On Sat, Jun 7, 2025 at 9:59 PM Lowell Hought <lowell(dot)hought(at)gmail(dot)com>
wrote:

> Wait, I spoke too soon. When I just ran the query I was on version 16.
> Give me a moment to shut down 16 and fire up 17 and I will try it again.
>
> Lowell
>
> On Sat, Jun 7, 2025 at 9:57 PM Lowell Hought <lowell(dot)hought(at)gmail(dot)com>
> wrote:
>
>> Yes! I just changed the parameter as you suggested and the query
>> returned as expected.
>> So I guess something changed between version 16 and version 17? Perhaps
>> the default for that setting?
>>
>> Lowell
>>
>> On Sat, Jun 7, 2025 at 9:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Lowell Hought <lowell(dot)hought(at)gmail(dot)com> writes:
>>> > If I run the query outside of the function it works as expected. But
>>> the function never returns.
>>>
>>> This isn't that surprising either: a query inside a function is
>>> often translated into a "generic" plan that doesn't depend on
>>> specific parameter values, typically sacrificing runtime to
>>> avoid repeated planning. Does it get any better if you do
>>> "set plan_cache_mode = force_custom_plan" before running the
>>> function?
>>>
>>> regards, tom lane
>>>
>>