Thread

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

    Tom Lane <tgl@sss.pgh.pa.us> — 1999-07-20T02:15:12Z

    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
    
    
  2. Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

    Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-23T22:01:33Z

    This seems to be the detail on the bug report.
    
    
    > 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
    
    
  3. Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-29T22:46:02Z

    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
    
    
  4. Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

    Uncle George <gatgul@voicenet.com> — 1999-11-29T23:54:47Z

    I'm sorry, the resultant node as returned is not expected. The solution, as
    provided,  did stop the insidious erasure of a field in a structure it did not own.
    I'm content ( but i dont know any better )
    If ur asking me what one is suppose to do at this point  - I dunno.
    gat
    
    Bruce Momjian wrote:
    
    > 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
    >
    > ************