Re: Data corruption/loss when altering tables (fwd) - Mailing list pgsql-bugs

From Michael Fuhr
Subject Re: Data corruption/loss when altering tables (fwd)
Date
Msg-id 20041122215640.GA82307@winnie.fuhr.org
Whole thread Raw
In response to Re: Data corruption/loss when altering tables (fwd)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Nov 22, 2004 at 03:44:25PM -0500, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Would LOAD 'plpgsql' work?  Would that cause a fresh compile of the
> > function the next time it's called, resulting in a new cached plan?
>
> I think that would cause plpgsql to lose track of its entire function
> table, which is a brute force way of doing that ... but it doesn't
> really solve Nicola's problem, because the nasty part of this is
> plans that are already cached by other backends.

Yeah, I was just mentioning a way to avoid having to reconnect the
current session if you know you've altered a table.  In another
message I suggested using EXECUTE to prevent plans from being
cached -- is there a better way in the current implementation?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_ctl -w start does not know that it has started postmaster
Next
From: Simon Riggs
Date:
Subject: Re: BUG #1320: 7.3.8 server RPM has file error