Re: Data corruption/loss when altering tables (fwd)

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/

In response to

Browse pgsql-bugs by date

  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)