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

Lowell Hought <lowell.hought@gmail.com>

From: Lowell Hought <lowell.hought@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, pgsql-bugs@lists.postgresql.org
Date: 2025-06-08T03:04:03Z
Lists: pgsql-bugs
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.hought@gmail.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.hought@gmail.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@sss.pgh.pa.us> wrote:
>>
>>> Lowell Hought <lowell.hought@gmail.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
>>>
>>