Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Uncle George <gatgul(at)voicenet(dot)com>, Jan Wieck <wieck(at)debis(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org
Subject: Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
Date: 1999-11-30 02:20:36
Message-ID: 18849.943928436@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-ports

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Any ideas on this one?

>> Uncle George <gatgul(at)voicenet(dot)com> writes:
>>>> In the regression test rules.sql there is this SQL command
>>>> update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
>>>> Which causes my alpha port to go core.
>>
>> Yeah. This was reported by Pedro Lobo on 11 June, and we've been
>> patiently waiting for Jan to decide what to do about it :-(
>>
>> You could stop the coredump by putting a test into ResolveNew:
>>
>> {
>> *nodePtr = copyObject(n);
>> + if (IsA(*nodePtr, Var))
>> ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
>> }
>>
>> but what's not so clear is what's supposed to happen when the
>> replacement item *isn't* a Var. I tried to convince myself that nothing
>> needed to happen in that case, but wasn't successful. (Presumably the
>> replacement expression contains no instances of the variable being
>> replaced, so recursing into it with ResolveNew shouldn't be needed
>> --- but maybe its varlevelsup values need adjusted?)

That code currently reads like:

/* Make a copy of the tlist item to return */
n = copyObject(n);
if (IsA(n, Var))
{
((Var *) n)->varlevelsup = this_varlevelsup;
}
/* XXX what to do if tlist item is NOT a var?
* Should we be using something like apply_RIR_adjust_sublevel?
*/
return n;

so it won't coredump when the tlist item is not a Var, but I'm not
convinced it does the right thing either. Jan is the only man who
understands that code well enough to say what needs to be done about
it...

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-11-30 02:28:28 Re: A bug in NOT IN (SELECT ...
Previous Message Tom Lane 1999-11-30 02:15:22 Re: [HACKERS] having bug report

Browse pgsql-ports by date

  From Date Subject
Next Message Bruce Momjian 1999-11-30 02:39:49 Re: [PORTS] Interface compile problems with 6.5.2 on DEC-Alpha
Previous Message Uncle George 1999-11-29 23:54:47 Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha