Re: prepare-alter-exec issue

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dhanaraj <Dhanaraj(dot)M(at)Sun(dot)COM>
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: prepare-alter-exec issue
Date: 2006-04-27 02:41:48
Message-ID: 200604270241.k3R2fmU00354@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


Added to TODO:

* Invalidate prepared queries, like INSERT, when the table definition
is altered

---------------------------------------------------------------------------

Dhanaraj wrote:
> The same bug was filed already in the end of Nov.
>
> There are two ways to fix this.
>
> 1) After altering the table, prepare buffer should be cleared
> or
> 2) The prepare stmt should be updated whenever alter query is executed.
>
> I hope that this bug will be fixed in the next version..
>
> Regards
> Dhanaraj
> Qingqing Zhou wrote:
> > I encounter a server(8.1.1) problem like this:
> >
> > create table tt(id int);
> > prepare p1(int) as insert into tt values($1);
> > execute p1(3);
> > alter table tt alter id type char(10);
> > execute p1(9999999);
> > select * from tt;
> > ^ server core dumps here
> >
> > Command "execute p1(9999999)" works because the prepared plan still treat
> > 9999999 as an integer, but "select * from tt" causes core dump because it
> > treats the attribute as type varlena char - so 9999999 becomes the varlen.
> >
> > This might be a known issue, but seems not mentioned in the document:
> > http://www.postgresql.org/docs/current/static/sql-prepare.html
> >
> >
> > Regards,
> > Qingqing
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Huxton 2006-04-27 15:16:34 Re: Error in returning setof records
Previous Message Marinos Yannikos 2006-04-26 23:17:01 pg_dump 8.1.2 with 7.4.2 server screws up with LATIN1 strings