Re: - Proposal for repreparing prepared statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: - Proposal for repreparing prepared statements
Date
Msg-id 16434.1158180602@sss.pgh.pa.us
Whole thread Raw
In response to Re: - Proposal for repreparing prepared statements  ("Marshall, Steve" <smarshall@wsi.com>)
List pgsql-hackers
"Marshall, Steve" <smarshall@wsi.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


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Lock partitions
Next
From: Mark Dilger
Date:
Subject: Re: Fixed length data types issue