Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> On reflection what seems most likely is simply that turning these
> otherwise-inlineable SQL functions into SECURITY DEFINER disabled
> inline-ing them, resulting in catastrophic degradation of the
> generated plans, such that they took a lot longer than you were
> accustomed to (they shouldn't have been "hung" though).
Ah, I had not considered that. That also explains why my attempts
to recreate the situation with "toy" tables didn't show the issue.
Also, it didn't occur to me until later to check whether a continue
and another backtrace showed things moving; all the evidence
suggested (in retrospect) that it was "doing something" rather than
being blocked, per se; but these are normally sub-second queries
which were killed after running over an hour, so I (probably
wrongly) assumed they were in an endless loop.
I will try again in just one site with a bit more care about which
functions I flag. If that goes OK, I'll have the confidence to go
forward with the application release.
In response to
pgsql-bugs by date
|Next:||From: Craig Ringer||Date: 2011-12-20 23:56:07|
|Subject: Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll"
|Previous:||From: Tom Lane||Date: 2011-12-20 21:53:19|
|Subject: Re: Security definer "generated column" function used in index |