Re: Dropping of indexes with cached PL query plans

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Jerry Sievers <jerry(at)jerrysievers(dot)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/