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 TABLE
Merlin> Time: 254.847 ms
Merlin> postgres=# EXECUTE ins_abc;
Merlin> INSERT 0 1
Merlin> Time: 0.452 ms
Merlin> postgres=# select * from abc;
Merlin> ERROR: invalid memory alloc 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