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 >>> >>