From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nicola Pero <n(dot)pero(at)mi(dot)flashnet(dot)it>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Data corruption/loss when altering tables (fwd) |
Date: | 2004-11-22 21:56:41 |
Message-ID: | 20041122215640.GA82307@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Nov 22, 2004 at 03:44:25PM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-11-23 00:32:39 | Re: BUG #1320: 7.3.8 server RPM has file error |
Previous Message | Nicola Pero | 2004-11-22 21:34:27 | Re: Data corruption/loss when altering tables (fwd) |