[HACKERS] Re: [QUESTIONS] Bug ? - Mailing list pgsql-hackers

From Bruce Momjian
Subject [HACKERS] Re: [QUESTIONS] Bug ?
Date
Msg-id fad83fb309db5def84bb2b1126fe7b33
Whole thread Raw
List pgsql-hackers
>
> Bruce, comments ?
> (I didn't change CVS!)
>
> Vadim
>
> > bench=> select t1.*, t2.gaga as t2gaga into table temp from tenk1 t1, tenk2 t2;
> > PQexec() -- Request was sent to backend, but backend closed the channel before responding.  This probably means the
backendterminated abnormally before or while processing the request. 
>
> Yes, we have bug here. It's fix for
> execUtils.c:setVarAttrLenForCreateTable()
> ---------
> 1158c1158
> <               rtentry = rt_fetch(var->varno, rangeTable);
> ---
> >               rtentry = rt_fetch(var->varnoold, rangeTable);
> 1162c1162
> <                               (*rd->rd_att->attrs[var->varattno-1]).attlen;
> ---
> >                               (*rd->rd_att->attrs[var->varoattno-1]).attlen;
> ---------
>
> I changed varno/varattno to varnoold/varoattno: in the case of joins
> varno-s may be INNER/OUTER (65000/65001) - you got crash from here, -
> varattno-s may be changed too.
> They are the same as varno/varattno if no join.

Yep, that is my code.  It is checking for the varchar() length to create
the new table.  I am not sure how non-old and old varattno values work
in this area, but if the 'old' variable works better, let's make the
change.

It may be that the 'old' varattno points to the proper range table
entry, and the non-old entry points to a pseudo-range table entry for a
inner/outer join.

Vadim, can you apply the change?  You seem to be in a better position
because you have a working patch there.

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

------------------------------

pgsql-hackers by date:

Previous
From: "Vadim B. Mikheev"
Date:
Subject: [HACKERS] Re: [PORTS] GEQO broken on 6-6-97?!?
Next
From: hakan@twins.iconsult.com (Hakan Tandogan)
Date:
Subject: Re: [HACKERS] Third Party Stuff