Обсуждение: varchar() troubles

I've been seeing trouble with varchar() columns for a little while, and
since it is still there with a fresh install of the development tree
it's time to report it:

postgres=> create table t (v varchar(80),i int);
CREATE
postgres=> insert into t values ('hi',1);
INSERT 18122 1
postgres=> select * from t;
v |i
--+-
hi|0
(1 row)

As you can see, the varchar() column apparently trashes the subsequent
column. I ran across it trying to verify the tutorial examples for the
documentation. If the varchar() is the last column in the table, the
problem does not crop up, at least in the simplest case:

postgres=> create table t2 (i int, v varchar(80));
CREATE
postgres=> insert into t2 values (2,'hi');
INSERT 18133 1
postgres=> select * from t2;
i|v
-+--
2|hi
(1 row)

Also, I believe that if the varchar() field is substantially shorter the
problem does not manifest itself:

postgres=> create table t4 (v varchar(4), i int);
CREATE
postgres=> insert into t4 values ('hi',4);
INSERT 18156 1
postgres=> select * from t4;
v |i
--+-
hi|4
(1 row)

but varchar(10) still shows the problem:

postgres=> create table t3 (v varchar(10), i int);
CREATE
postgres=> insert into t3 values ('hi',3);
INSERT 18145 1
postgres=> select * from t3;
v |i
--+-
hi|0
(1 row)

This is from the development source as of around 1998-01-12 14:30 GMT

                                                                    -
Tom

>
> I've been seeing trouble with varchar() columns for a little while, and
> since it is still there with a fresh install of the development tree
> it's time to report it:
>
> postgres=> create table t (v varchar(80),i int);
> CREATE
> postgres=> insert into t values ('hi',1);
> INSERT 18122 1
> postgres=> select * from t;
> v |i
> --+-
> hi|0
> (1 row)

Did you see this before or only after the varchar() length change I
made?


--
Bruce Momjian
maillist@candle.pha.pa.us

Bruce Momjian wrote:

> >
> > I've been seeing trouble with varchar() columns for a little while, and
> > since it is still there with a fresh install of the development tree
> > it's time to report it:
> >
> > postgres=> create table t (v varchar(80),i int);
> > CREATE
> > postgres=> insert into t values ('hi',1);
> > INSERT 18122 1
> > postgres=> select * from t;
> > v |i
> > --+-
> > hi|0
> > (1 row)
>
> Did you see this before or only after the varchar() length change I
> made?

Pretty sure only after but it's hard to tell for sure. My trees for 971204
and 971222 both core dump on inserts to varchar, but I can't remember what
else I was doing with the trees at the time. v6.2.1p5 works OK on this:

postgres=> create table t (v varchar(80),i int);
CREATE
postgres=> insert into t values ('hi',1);
INSERT 142735 1
postgres=> select * from t;
v |i
--+-
hi|1
(1 row)

                                                                        -
Tom

> Pretty sure only after but it's hard to tell for sure. My trees for 971204
> and 971222 both core dump on inserts to varchar, but I can't remember what
> else I was doing with the trees at the time. v6.2.1p5 works OK on this:
>
> postgres=> create table t (v varchar(80),i int);
> CREATE
> postgres=> insert into t values ('hi',1);
> INSERT 142735 1
> postgres=> select * from t;
> v |i
> --+-
> hi|1
> (1 row)

I am working on it.  Look at this:

    test=> create table t15 (x varchar(7),x1 int, x2 int, x3 int)
    test-> ;
    CREATE
    test=> insert into t15 values ('as',1,2,3);
    INSERT 143436 1
    test=> select * from t15;
    x |x1|x2|x3
    --+--+--+--
    as| 2| 3| 0
    (1 row)

Srange, huh?

--
Bruce Momjian
maillist@candle.pha.pa.us

> Pretty sure only after but it's hard to tell for sure. My trees for 971204
> and 971222 both core dump on inserts to varchar, but I can't remember what
> else I was doing with the trees at the time. v6.2.1p5 works OK on this:
>
> postgres=> create table t (v varchar(80),i int);
> CREATE
> postgres=> insert into t values ('hi',1);
> INSERT 142735 1
> postgres=> select * from t;
> v |i
> --+-
> hi|1
> (1 row)

The data on disk is OK, so it must be the retrieve code.

--
Bruce Momjian
maillist@candle.pha.pa.us

> Pretty sure only after but it's hard to tell for sure. My trees for 971204
> and 971222 both core dump on inserts to varchar, but I can't remember what
> else I was doing with the trees at the time.

I now recall that the varchar code was broken during this time (for who knows
how long?), as I discovered when trying to reproduce the tutorial results for
the documentation.

The problem was that some things were copied using VARSIZE rather than
subtracting out VARHDRSZ first (actually, I think it might have use
sizeof(int) and other dangers too). I patched that near the end of the year
and my 980101.d tree and 980106.d tree do not exhibit the symptom:

postgres=> create table t (v varchar(80),i int);
CREATE
postgres=> insert into t values ('hi', 1);
INSERT 643562 1
postgres=> select * from t;
v |i
--+-
hi|1
(1 row)

Hope this helps :/

                                             - Tom

>
> > Pretty sure only after but it's hard to tell for sure. My trees for 971204
> > and 971222 both core dump on inserts to varchar, but I can't remember what
> > else I was doing with the trees at the time.
>
> I now recall that the varchar code was broken during this time (for who knows
> how long?), as I discovered when trying to reproduce the tutorial results for
> the documentation.
>
> The problem was that some things were copied using VARSIZE rather than
> subtracting out VARHDRSZ first (actually, I think it might have use
> sizeof(int) and other dangers too). I patched that near the end of the year
> and my 980101.d tree and 980106.d tree do not exhibit the symptom:
>
> postgres=> create table t (v varchar(80),i int);
> CREATE
> postgres=> insert into t values ('hi', 1);
> INSERT 643562 1
> postgres=> select * from t;
> v |i
> --+-
> hi|1
> (1 row)

I have found that ExecEvalVar() uses a descriptor that has the attr
length set to the maximum, instead of -1.  The ExecTypeFromTL() comment
says:

/* ----------------------------------------------------------------
 *      ExecTypeFromTL
 *
 *      Currently there are about 4 different places where we create
 *      TupleDescriptors.  They should all be merged, or perhaps
 *      be rewritten to call BuildDesc().
 *

Clearly stating that the tuple descriptors in the system are created in
several places.  Some places have the length set wrong.  I am going to
have to take a look at all those places, and make sure they have
consistent behaviour.

--
Bruce Momjian
maillist@candle.pha.pa.us

>
> Bruce,
>
> The new varchar() stuff looks good, just a minor problem with "select into"
> where the new table does not seem to get a copy of the atttypmod value
> from the source table.
>
> I had a quick look at the code but guess you'll find the problem 10 times
> faster than I could.

OK, I have fixed this.  The real way to fix this it to add restypmod to
Resdom, and pass the value all the way through the engine, so tupDesc
always has the proper atttypmod value, but it is not clear how to do
this in the parser, so I put the code back in to just do a lookup in
execMain/execUtils when doing an SELECT * INTO TABLE.

If we start using atttypmod more, we will have to do this.

--
Bruce Momjian
maillist@candle.pha.pa.us