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/
