[HACKERS] Re: [QUESTIONS] Bug ?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема [HACKERS] Re: [QUESTIONS] Bug ?
Дата
Msg-id 2fc0ef984a32effdc311faa01a9389bb
обсуждение исходный текст
Список 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 по дате отправления: