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:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 2:08 PM To: Marshall, Steve Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] - Proposal for repreparing prepared statements Stephen Marshall <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
