Обсуждение: Dropping of indexes with cached PL query plans

Hello.

I am curious what (if any) reliable solution/workaround there is in
cases where objects that are a part of a currently cached query plan
disappear unexpectedly.

Using JDBC and pooled connections, our production system has at any
time 120 or so live connections, most in an idle state.  They must
remain alive however for proper operation of the app server.

Any of these connections that may have previously executed PL
functions which planned an index lookup are now going to fault if same
index goes away.

Had wondered if a postmaster 'reload' would elicit a recompiling of
func query plans (did *not* see this in the docs but was hopeful...).

Anyway, we find that reloading the function definitions allows
continued proper operation.  Of course, due to quite a lot of
indirection in func and trigger invocation, identifying just the right
funcs to reload seems unfeasible.  We don't relish the thought of
reloading all 400+ of them after an index drop.

For that matter, I am averse to reloading *any* func defs on a live
prod machine either as matter of principle.

Arg! But the nature of business at this company makes difficult a
strict adherance to "hands off prod boxes" methodology.

Comments?

--
-------------------------------------------------------------------------------
Jerry Sievers   305 854-3001 (home)     WWW ECommerce Consultant
                305 321-1144 (mobile    http://www.JerrySievers.com/

Jerry Sievers <jerry@jerrysievers.com> writes:
> Any of these connections that may have previously executed PL
> functions which planned an index lookup are now going to fault if same
> index goes away.

> Had wondered if a postmaster 'reload' would elicit a recompiling of
> func query plans (did *not* see this in the docs but was hopeful...).

Starting a fresh session (database connection) is sufficient, you need
not bounce the postmaster as such.

We are looking at making replanning happen automatically after a schema
change; I'm hopeful that that gets done for 8.2.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Jerry Sievers <jerry@jerrysievers.com> writes:
> > Any of these connections that may have previously executed PL
> > functions which planned an index lookup are now going to fault if same
> > index goes away.
>
> > Had wondered if a postmaster 'reload' would elicit a recompiling of
> > func query plans (did *not* see this in the docs but was hopeful...).
>
> Starting a fresh session (database connection) is sufficient, you need
> not bounce the postmaster as such.

Yes Tom, thanks.

Note that I am referring to the 'reload' operation, that is; simple
HUPping of postmaster.  But of course, this doesn't cause cached query
plans to be recalc'd anyway, as you point out below (at least, not
presently).

I wonder if you'd comment on the (apparently) useful workaround of
doing a CREATE or REPLACE FUNCTION on the PL funcs?

This does work, on 8.0 systems, though perhaps isn't a robust solution
for some other reason.

I do understand also that such a solution will *not* solve the same
problem as it relates to Postgres prepared statements.  As I
understant it, only the active session could deallocate and re-prepare
such a statement.

> We are looking at making replanning happen automatically after a schema
> change; I'm hopeful that that gets done for 8.2.

That would be excellent IMO.

Failing that, if systemic replanning is deemed too heavy to initiate
on any DDL change; something like  an administrator forced re-cacheing
might suffice.

Eg; pg_ctl recache  (SIGUSR1 or somesuch tells running sessions to
replan any cached queries).

At any rate, great work past and present.

Thanks!

--
-------------------------------------------------------------------------------
Jerry Sievers   305 854-3001 (home)     WWW ECommerce Consultant
                305 321-1144 (mobile    http://www.JerrySievers.com/