Thread

  1. PostgreSQL v6.4 BETA2 ...

    Marc G. Fournier <scrappy@hub.org> — 1998-10-13T22:50:05Z

    I just built and regression tested the current source tree on both Solaris
    x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    smooth...
    
    Any arguments against getting a BETA2 out tomorrow afternoon?  
    
    Marc G. Fournier                               scrappy@hub.org
    Systems Administrator @ hub.org                    
    scrappy@{postgresql|isc}.org                       ICQ#7615664
    
    
    
  2. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-14T01:33:45Z

    > Any arguments against getting a BETA2 out tomorrow afternoon?
    
    None, though I've just stumbled across some config stuff which would be
    nice to clean up.
    
    It came up when I tried upgrading compilers. The new one omitted an
    explicit cpp, the preprocessor. Builds failed because references to it
    are hardcoded, along with paths to find it, in at least two script files
    for the backend. 
    
    It also turns out that autoconf already checks for cpp, or the
    equivalent, but the result wasn't being used. So, fine, but...
    
    autoconf concludes that "gcc -E" is equivalent to cpp on my system. And
    it is, except that it needs an explicit bare "-" argument to try reading
    from a pipe, which is how cpp was being used. I can test for "gcc" being
    in the command, and add the argument, _or_ can change the scripts to
    write a temporary file instead (they already write some temp files).
    
    Comments? Suggestions??
    
                        - Tom
    
    Oh, I'm probably going to revert back to the compiler package which
    includes cpp...
    
    
  3. RE: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Taral <taral@mail.utexas.edu> — 1998-10-14T02:56:39Z

    > autoconf concludes that "gcc -E" is equivalent to cpp on my system. And
    > it is, except that it needs an explicit bare "-" argument to try reading
    > from a pipe, which is how cpp was being used. I can test for "gcc" being
    > in the command, and add the argument, _or_ can change the scripts to
    > write a temporary file instead (they already write some temp files).
    
    Add the following to configure.in after AC_PROG_CPP and use the resultant
    flag from CPPSTDIN: (either nothing or -)
    
    --- cut here ---
    AC_DEFUN(AC_TRY_CPPSTDIN,
    [AC_REQUIRE_CPP()dnl
    cat > conftest.$ac_ext <<EOF
    [#]line __oline__ "configure"
    #include "confdefs.h"
    [$1]
    EOF
    ac_try="$ac_cpp $CPPSTDIN <conftest.$ac_ext >/dev/null 2>conftest.out"
    AC_TRY_EVAL(ac_try)
    ac_err=`grep -v '^ *+' conftest.out`
    if test -z "$ac_err"; then
      ifelse([$2], , :, [rm -rf conftest*
      $2])
    else
      echo "$ac_err" >&AC_FD_CC
      echo "configure: failed program was:" >&AC_FD_CC
      cat conftest.$ac_ext >&AC_FD_CC
    ifelse([$3], , , [  rm -rf conftest*
      $3
    ])dnl
    fi
    rm -f conftest*])
    
    AC_MSG_CHECKING(how to use cpp with stdin)
    if test -z "$CPPSTDIN"; then
    AC_CACHE_VAL(ac_cv_cpp_stdin,
    [  CPPSTDIN=""
      AC_TRY_CPPSTDIN([#include <assert.h>
    Syntax Error], , CPPSTDIN="-")
      ac_cv_cpp_stdin="$CPPSTDIN"])
      CPPSTDIN="$ac_cv_cpp_stdin"
    else
      ac_cv_cpp_stdin="$CPPSTDIN"
    fi
    AC_MSG_RESULT($CPP $CPPSTDIN)
    AC_SUBST(CPPSTDIN)
    --- cut here ---
    
    Taral
    
    P.S. Yes, do use the DEFUN just in case we want to add more broken variants
    later :)
    
    
    
  4. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Jan Wieck <jwieck@debis.com> — 1998-10-14T07:51:36Z

    >
    >
    > I just built and regression tested the current source tree on both Solaris
    > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    > smooth...
    >
    > Any arguments against getting a BETA2 out tomorrow afternoon?
    
        Have  a crashing backend after a huge transaction on the next
        insert into a table with indices. Crash is  reproducable  and
        seems to be due to a corrupted index file.
    
        Recompiling with COPT=-g now...
    
    >
    > Marc G. Fournier                               scrappy@hub.org
    > Systems Administrator @ hub.org
    > scrappy@{postgresql|isc}.org                       ICQ#7615664
    >
    >
    >
    
    
    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] PostgreSQL v6.4 BETA2 ...

    Jan Wieck <jwieck@debis.com> — 1998-10-14T14:42:41Z

    That was me:
    >
    > >
    > >
    > > I just built and regression tested the current source tree on both Solaris
    > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    > > smooth...
    > >
    > > Any arguments against getting a BETA2 out tomorrow afternoon?
    >
    >     Have  a crashing backend after a huge transaction on the next
    >     insert into a table with indices. Crash is  reproducable  and
    >     seems to be due to a corrupted index file.
    >
    >     Recompiling with COPT=-g now...
    >
    
        Harrr  -  using  text_ops  on  an  int4 field in CREATE INDEX
        doesn't make much sense.
    
        Bruce, please add 6.5 TODO:
    
        Parser must check on CREATE INDEX that the opcdeftype of  the
        used  operator  class is compatible with the indexed field or
        the index functions return type.
    
    
    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) #
    
    
    
    
  6. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-14T17:01:32Z

    > 
    >     Harrr  -  using  text_ops  on  an  int4 field in CREATE INDEX
    >     doesn't make much sense.
    > 
    >     Bruce, please add 6.5 TODO:
    > 
    >     Parser must check on CREATE INDEX that the opcdeftype of  the
    >     used  operator  class is compatible with the indexed field or
    >     the index functions return type.
    
    But, we don't require ops* anymore.  Should we prevent people from using
    whatever ops they want?
    
    
    -- 
      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
    
    
  7. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Marc G. Fournier <scrappy@hub.org> — 1998-10-14T19:29:03Z

    On Wed, 14 Oct 1998, Jan Wieck wrote:
    
    > >
    > >
    > > I just built and regression tested the current source tree on both Solaris
    > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    > > smooth...
    > >
    > > Any arguments against getting a BETA2 out tomorrow afternoon?
    > 
    >     Have  a crashing backend after a huge transaction on the next
    >     insert into a table with indices. Crash is  reproducable  and
    >     seems to be due to a corrupted index file.
    > 
    >     Recompiling with COPT=-g now...
    
    	I saw Bruce's last on this...will wait until you guys have this
    sorted out before I build the snapshot...
    
    Marc G. Fournier                               scrappy@hub.org
    Systems Administrator @ hub.org                    
    scrappy@{postgresql|isc}.org                       ICQ#7615664
    
    
    
  8. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Jan Wieck <jwieck@debis.com> — 1998-10-14T21:06:19Z

    > 
    > On Wed, 14 Oct 1998, Jan Wieck wrote:
    > 
    > > >
    > > >
    > > > I just built and regression tested the current source tree on both Solaris
    > > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    > > > smooth...
    > > >
    > > > Any arguments against getting a BETA2 out tomorrow afternoon?
    > > 
    > >     Have  a crashing backend after a huge transaction on the next
    > >     insert into a table with indices. Crash is  reproducable  and
    > >     seems to be due to a corrupted index file.
    > > 
    > >     Recompiling with COPT=-g now...
    > 
    > 	I saw Bruce's last on this...will wait until you guys have this
    > sorted out before I build the snapshot...
    > 
    
        Was my fault - not a bug.
    
    
    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) #
    
    
    
  9. Re: [HACKERS] PostgreSQL v6.4 BETA2 ...

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-14T23:39:40Z

    > On Wed, 14 Oct 1998, Jan Wieck wrote:
    > 
    > > >
    > > >
    > > > I just built and regression tested the current source tree on both Solaris
    > > > x86 and Solaris Sparc, and other then a few bugs that I've fixed, it was
    > > > smooth...
    > > >
    > > > Any arguments against getting a BETA2 out tomorrow afternoon?
    > > 
    > >     Have  a crashing backend after a huge transaction on the next
    > >     insert into a table with indices. Crash is  reproducable  and
    > >     seems to be due to a corrupted index file.
    > > 
    > >     Recompiling with COPT=-g now...
    > 
    > 	I saw Bruce's last on this...will wait until you guys have this
    > sorted out before I build the snapshot...
    
    Fixed.  He had the wrote ops_ on the index.
    
    -- 
      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