BUG #11402: Prepared statement cache invalidation and unknown types

Поиск
Список
Период
Сортировка
От marko@joh.to
Тема BUG #11402: Prepared statement cache invalidation and unknown types
Дата
Msg-id 20140911215805.2484.10673@wrigleys.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #11402: Prepared statement cache invalidation and unknown types  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      11402
Logged by:          Marko Tiikkaja
Email address:      marko@joh.to
PostgreSQL version: 9.4beta2
Operating system:   Any
Description:

Hi,

This might have been reported before, but I hit this quite horrible
behaviour with prepared statements this week.  Observeth:

local:marko=# create table foo(a int);
CREATE TABLE
local:marko=#* prepare qwr(unknown) as select * from foo where a = $1;
PREPARE
local:marko=#* execute qwr('1');
 a
---
(0 rows)

local:marko=#* alter table foo alter column a type text;
ALTER TABLE
local:marko=#* execute qwr('1');
ERROR:  operator does not exist: text = integer
HINT:  No operator matches the given name and argument type(s). You might
need to add explicit type casts.

I hit the behaviour on 9.1 originally with functions, but tested it against
a reasonably fresh HEAD and it was still broken.  Somehow it seems that the
prepared statement isn't willing to forget the data type of the argument
after it has been resolved once (even though it was specified to be unknown
:-( ).  This leads to some grotesque cache invalidation code in our API.

If this has been discussed before and has been decided to not be worth
fixing, feel free to call me names, but I just thought I'd bring it to your
attention before I forget again.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Следующее
От: Roman Konoval
Дата:
Сообщение: Memory leak during delete with sequential scan