[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 по дате отправления: