Thread: bug in prepared statements, alter table <8.3

postgres=# create table abc (a int, b int);
CREATE TABLE
Time: 492.417 ms
postgres=# insert into abc values (1,2);
INSERT 0 1
Time: 16.602 ms
postgres=# prepare ins_abc as insert into abc values(1,2);
PREPARE
Time: 0.248 ms
postgres=# alter table abc alter a type numeric;
ALTER TABLE
Time: 254.847 ms
postgres=# EXECUTE ins_abc;
INSERT 0 1
Time: 0.452 ms
postgres=# select * from abc;
ERROR:  invalid memory alloc request size 18446744073709551610

:-)

h/t to rhodium toad.

merlin

>>>>> "Merlin" == "Merlin Moncure" <mmoncure@gmail.com> writes:
Merlin> postgres=# alter table abc alter a type numeric;Merlin> ALTER TABLEMerlin> Time: 254.847 msMerlin> postgres=#
EXECUTEins_abc;Merlin> INSERT 0 1Merlin> Time: 0.452 msMerlin> postgres=# select * from abc;Merlin> ERROR:  invalid
memoryalloc request size 18446744073709551610
 
Merlin> :-)
Merlin> h/t to rhodium toad.

This is fairly obviously a simple consequence of the lack of plan
invalidation, it just happens to be more serious than most (you can,
as a normal user, break the backend in a dozen different ways, from
bad data or incomprehensible error messages up through SEGVs).

-- 
Andrew (irc:RhodiumToad)

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> This is fairly obviously a simple consequence of the lack of plan
> invalidation, it just happens to be more serious than most

Hmm, we plugged the correspoding hole on the SELECT side awhile back,
but it seems that INSERT/UPDATE may need some defenses too.
        regards, tom lane