Re: - Proposal for repreparing prepared statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marshall, Steve" <smarshall(at)wsi(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: - Proposal for repreparing prepared statements
Date: 2006-09-13 20:50:02
Message-ID: 16434.1158180602@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Marshall, Steve" <smarshall(at)wsi(dot)com> writes:
> I want to be able to tell a backend to reinitialize some of the cached
> data it is holding in static variables. Generally I want to do this
> when the something "cached" in memory has gotten out-of-sync with what
> is in the database. The two examples that affect me are:

> 1. A database table has changed in its structure, and the prepared
> statements related to it either no longer work, or do the wrong thing.

This we need to fix.

> 2. A TCL module in pltcl_modules is updated with a new version, but
> running processes that have already executed a function from this module
> do not pick up the change.

To be frank, this is not Postgres' problem, it's pltcl's. I think the
pltcl_modules facility is poorly designed (precisely because it doesn't
fit into any sane way of handling the schema-update problem) and needs
to be thrown out and redone. If the units you were reloading were
Postgres functions, or had some other way of being represented in the
system catalogs, then we'd have a reasonable way to attack the problem.
But forcing a reload of pltcl.so is nothing but a kluge --- it leaks
memory like there's no tomorrow, and it's only an accident that it fails
to crash. I don't want to design a further kluge on top of it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2006-09-13 20:52:38 Re: Fixed length data types issue
Previous Message Jim Nasby 2006-09-13 20:37:41 Re: Lock partitions