> Is this a known problem?
>
> CREATE TABLE test (
> plt int2 PRIMARY KEY,
> state CHAR(5) NOT NULL DEFAULT 'new',
> used boolean NOT NULL DEFAULT 'f',
> id int4
> );
>
> INSERT INTO test (plt, id) VALUES (1, 1);
> INSERT INTO test (plt, id) VALUES (2, 2);
> INSERT INTO test (plt, id) VALUES (3, 3);
>
> SELECT * FROM test;
>
> plt|state|used|id
> ---+-----+----+--
> 1|new |f | 1
> 2|new |f | 2
> 3|new |f | 3
> (3 rows)
>
> UPDATE test SET state = 'diff' WHERE plt = 1;
> SELECT * FROM test;
>
> plt|state|used| id
> ---+-----+----+-----
> 2|new |f | 2
> 3|new |f | 3
> 1|diff |t |26144
> (3 rows)
>
> ???
This is scary, but not unexpected. I have a bug report in my mailbox
that describes a similar problem with default. I am sure it is the same
cause. Somewhere, default is broken, and it is on the Open Items list.
I believe it is an improper default length field or rounding of length.
I looked at it once, but could not find the cause.
Report is below.
---------------------------------------------------------------------------
Hi,
I found a bug in 6.4.2 which seems to be
related to the char(n) type and shows up
if one assigns a zero-length default value.
Here is an example:
test=> create table t1 (
test-> str1 char(2) default '', <---- note this one
test-> str2 text default '',
test-> str3 text default ''
test-> );
CREATE
test=> insert into t1 values ('aa', 'string2', 'string3');
INSERT 91278 1
test=> insert into t1 (str3) values ('string3');
INSERT 91279 1
test=>test=> select * from t1;
Backend message type 0x44 arrived while idle
Backend message type 0x44 arrived while idle
We have lost the connection to the backend, so further processing is
impossible. Terminating.
If the table is created as
create table t1 ( str1 char(2) default ' ', str2 text default '', str3 text default ''
);
the crash doesn't happen.
Regards
Erich
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026