Thread

  1. Open 6.3 issues

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-25T15:22:45Z

    First, with Jan's fix, initdb works fine now.
    
    Here are the open issues.  IMHO, none of these are show-stoppers.
    
    ---------------------------------------------------------------------------
    
    Self-join optimizer performance problem
    Get interfaces fixed for new protocol
    Profiling improvements?
    Problem with tables >2Gb, add elog()?
    Do we want to add timestamps to elog messages?
    ScanKeyData missing initializations
    Alpha/64-bit issues, mkoidname() problem
    large objects memory exhaustion
    Commit sgml document sources(Thomas)
    Commit html documents(Thomas)
    Commit postscript documents(Thomas)
    
    
    -- 
    Bruce Momjian                          |  830 Blythe Avenue
    maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
      +  If your life is a hard drive,     |  (610) 353-9879(w)
      +  Christ can be your backup.        |  (610) 853-3000(h)
    
    
  2. Re: [HACKERS] Open 6.3 issues

    Jan Wieck <jwieck@debis.com> — 1998-02-25T15:43:45Z

    > 
    > First, with Jan's fix, initdb works fine now.
    > 
    > Here are the open issues.  IMHO, none of these are show-stoppers.
    > 
    > ---------------------------------------------------------------------------
    > 
    > Self-join optimizer performance problem
    > Get interfaces fixed for new protocol
    > Profiling improvements?
    > Problem with tables >2Gb, add elog()?
    > Do we want to add timestamps to elog messages?
    > ScanKeyData missing initializations
    
        More details on missing initializations of ScanKeyData pleas.
        Might have some time now since the other permission and setuid
        things are delayed for 6.4.
    
    
    Jan
    
    -- 
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #
    
    
    
  3. Re: [HACKERS] Open 6.3 issues

    Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-25T16:32:13Z

    Jan Wieck wrote:
    > 
    > > ScanKeyData missing initializations
    > 
    >     More details on missing initializations of ScanKeyData pleas.
    >     Might have some time now since the other permission and setuid
    >     things are delayed for 6.4.
    
    There was one place in selfuncs.c where scan key was initialized
    directly by assignment values to structure' fields 
    (without ScanKeyEntryInitialize) and so new 6.3 fields were
    not initialized at all. One should check all code...
    
    Vadim
    
    
  4. Re: [HACKERS] Open 6.3 issues

    Jan Wieck <jwieck@debis.com> — 1998-02-25T17:22:48Z

    > 
    > Jan Wieck wrote:
    > > 
    > > > ScanKeyData missing initializations
    > > 
    > >     More details on missing initializations of ScanKeyData pleas.
    > >     Might have some time now since the other permission and setuid
    > >     things are delayed for 6.4.
    > 
    > There was one place in selfuncs.c where scan key was initialized
    > directly by assignment values to structure' fields 
    > (without ScanKeyEntryInitialize) and so new 6.3 fields were
    > not initialized at all. One should check all code...
    
        Haven't found any more places where sk_attno is assigned a
        value and where no previous ScanKeyEntryInitialize() is
        done. Think it's already fixed then.
    
    
    Jan
    
    -- 
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #
    
    
    
  5. Re: [HACKERS] Open 6.3 issues

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-25T17:25:06Z

    > Here are the open issues.  IMHO, none of these are show-stoppers.
    >
    > ---------------------------------------------------------------------------
    >
    > Self-join optimizer performance problem
    > Get interfaces fixed for new protocol
    > Profiling improvements?
    > Problem with tables >2Gb, add elog()?
    > Do we want to add timestamps to elog messages?
    > ScanKeyData missing initializations
    > Alpha/64-bit issues, mkoidname() problem
    > large objects memory exhaustion
    > Commit sgml document sources(Thomas)
    > Commit html documents(Thomas)
    > Commit postscript documents(Thomas)
    
    I would like the new docs to be considered "show stoppers", but expect that
    they will be committed before March. That is 3 days away and I have completed
    the tutorial and user's guide packages. Just need to redraw one of the other
    figures (1 hour?) and then massage the programmer's guide and administrator's
    guide (1-2 hours each), and then commit.
    
    Hmm, I think that I will go ahead and put some of the products into the cvs
    tree soon so folks can work out any installation problems. OK?
    
                                                                 - Tom
    
    
    
  6. Re: [HACKERS] Open 6.3 issues

    Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-25T23:00:41Z

    Jan Wieck wrote:
    > 
    > >
    > > Jan Wieck wrote:
    > > >
    > > > > ScanKeyData missing initializations
    > > >
    > > >     More details on missing initializations of ScanKeyData pleas.
    > > >     Might have some time now since the other permission and setuid
    > > >     things are delayed for 6.4.
    > >
    > > There was one place in selfuncs.c where scan key was initialized
    > > directly by assignment values to structure' fields
    > > (without ScanKeyEntryInitialize) and so new 6.3 fields were
    > > not initialized at all. One should check all code...
    > 
    >     Haven't found any more places where sk_attno is assigned a
    >     value and where no previous ScanKeyEntryInitialize() is
    >     done. Think it's already fixed then.
    
    Ok, but the problem was in un-initialized sk_func->fn_oid (sorry)...
    
    Vadim