Re: - Proposal for repreparing prepared statements

Tom,

Thanks for the update on the roadmap. I have a couple of questions:

1. Is the invalidation of stored plans going to be part of 8.2? If not,
any idea when it would be available? I'd be willing to work on this, if
it would help.

2. Is there any plan for the other part of my proposal, i.e. the ability
to force one or all backends to reload their dynamically linked
libraries? This is needed by backends that use loadable modules with
procedural languages (like pltcl_modules) in cases where a loadable
module gets updated.

Thanks,
Steve

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, September 13, 2006 2:08 PM
To: Marshall, Steve
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] - Proposal for repreparing prepared statements

Stephen Marshall <smarshall(at)wsi(dot)com> writes:
> The following is a proposal for work I'd like to do to force
> long-running backend processes to reprepare their prepared statements.
> It would be used in cases where the user knows they have made a
> database change that will invalidate an existing prepared statement.

There should be no need for users to concern themselves with this. The
direction we've been intending to go in is to automatically invalidate
stored plans when any related schema or statistics change occurs,
forcing a re-plan on any subsequent use. See past discussions (IIRC,
Neil Conway actually did some work on this idea earlier this year, but
didn't get it done).

The appropriate cross-backend communication mechanism already exists:
it's the catcache/relcache invalidation code. No need to fool with
finding a spare signal; and you can't do any meaningful work in a signal
handler anyway.

regards, tom lane