Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
Date
Msg-id 199911292246.RAA16125@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] RedHat6.0 & Alpha  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Any ideas on this one?

> Uncle George <gatgul@voicenet.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?)
>
>             regards, tom lane
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded