Thread

  1. Re: Postgresql broken

    Cristian Gafton <gafton@redhat.com> — 1998-02-26T18:51:45Z

    On Thu, 26 Feb 1998, Dwight Johnson wrote:
    
    > I agree. Can someone track down the RH5.0 rpm packager so we can start a dialog?
    
    Hello,
    
    I am the packager for the RH 5.0 postgres RPM. What's wrong with it ?
    
    > PostgreSQL-6.3 will be released in a few days, and it would be nice to resolve
    > these issues.
    
    Looking forward for this release...
    
    Best wishes,
    
    Cristian
    --
    ----------------------------------------------------------------------
    Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     UNIX is user friendly. It's just selective about who its friends are.
    
    
    
  2. Re: [HACKERS] Re: Postgresql broken

    Marc Fournier <scrappy@hub.org> — 1998-02-26T19:20:56Z

    On Thu, 26 Feb 1998, Cristian Gafton wrote:
    
    > On Thu, 26 Feb 1998, Dwight Johnson wrote:
    > 
    > > I agree. Can someone track down the RH5.0 rpm packager so we can start a dialog?
    > 
    > Hello,
    > 
    > I am the packager for the RH 5.0 postgres RPM. What's wrong with it ?
    
    Hi Christian...
    
    	I don't currently deal with Linux, so don't know what problems
    exist with the RPM, but would be possible for you to take the current
    snapshot, and build an RPM for that?  Then upload it to our bindist
    directory so that ppl can take alook at it before the release, to check
    for any problems?
    
    
    
    
  3. Re: [HACKERS] Re: Postgresql broken

    Cristian Gafton <gafton@redhat.com> — 1998-02-26T19:25:00Z

    On Thu, 26 Feb 1998, The Hermit Hacker wrote:
    
    > 	I don't currently deal with Linux, so don't know what problems
    > exist with the RPM, but would be possible for you to take the current
    > snapshot, and build an RPM for that?  Then upload it to our bindist
    
    Sure. I am downloading the snapshot now, and I will build RPMs and upload
    them to ftp://ftp.redhat.com/home/gafton/pgsql, if you want to point out
    ppl to a kind-of-official RH rpm.
    
    Best wishes,
    
    Cristian
    --
    ----------------------------------------------------------------------
    Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     UNIX is user friendly. It's just selective about who its friends are.
    
    
    
  4. Re: [HACKERS] Re: Postgresql broken

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-27T03:13:34Z

    > I am the packager for the RH 5.0 postgres RPM. What's wrong with it ?
    
    Hi Cristian. I'm developing Postgres on RH4.2 at home, and have RH5.0 running at
    work. There are three known problems with the Postgres packages (some of which are
    likely not directly related to the packaging itself):
    
    1) You have compiled the package with USE_LOCALE enabled. However, neither of my
    machines behaves properly with that (including a clean build from source on RH4.2).
    The test is to start up psql and try
    
      select '$1.00'::money;
    
    which fails. I believe this works on other platforms, and I distinctly recall getting
    this to work on my development machine (in fact I helped implement it), but afaik
    that was pre-RH4.2. My small test program which exercises the locale support in libc
    also no longer works under RH4.2, though by now that may be from my mucking with it
    trying to get it to work.
    
    2) pre-glibc2.0.7 has rounding bugs which cause odd results in some date/time
    routines. The test is to try
    
      select '4 hours'::timespan;
    
    which will return '3 hours 59 mins 60 secs' on a machine with problems. We have
    reports from someone running Debian that glibc2.0.7-pre1 (?) fixes the problem. Any
    idea on when glibc2.0.7 might be available?
    
    3) the ownership of the data area is incorrect as shipped (I assume this is
    rpm-specific). On my RH5.0 machine, which is a VAResearch system with Linux/Postgres
    preinstalled, the data area was owned by root, and the backend cannot start up. If
    the ownership is changed to the postgres account then the backend starts.
    
    > > PostgreSQL-6.3 will be released in a few days, and it would be nice to resolve
    > > these issues.
    
    Thanks for building a new RPM. I'll try it at work on my production machine tomorrow.
    Also, we will have new documentation in v6.3, including html and hardcopy, and you
    will want to repackage that too. Look in the doc directory (in a day or two; I'm
    still building the docs and haven't committed anything yet to the source tree).
    
    Best regards.
    
                                                      - Tom
    
    
    
  5. Re: [HACKERS] Re: Postgresql broken

    Cristian Gafton <gafton@redhat.com> — 1998-03-01T09:32:53Z

    On Fri, 27 Feb 1998, Thomas G. Lockhart wrote:
    
    > The test is to start up psql and try
    > 
    >   select '$1.00'::money;
    > 
    > which fails. I believe this works on other platforms, and I distinctly recall getting
    
    That is true, it fails. However, if you could point to me where exactly
    something is going wrong I could try and have a look at it. I don't really
    feel like digging into postgresql source to see which functions are at
    fault. A small C test program will be nice.
    
    > 2) pre-glibc2.0.7 has rounding bugs which cause odd results in some date/time
    > routines. The test is to try
    > 
    >   select '4 hours'::timespan;
    
    Yepp, it fails.
    
    > which will return '3 hours 59 mins 60 secs' on a machine with problems. We have
    > reports from someone running Debian that glibc2.0.7-pre1 (?) fixes the problem. Any
    > idea on when glibc2.0.7 might be available?
    
    the 2.0.7pre1 is available. However, if the debian folks fixed this
    problem, I can tell you that their patch didn't made it so far in the
    glibc source tree. Again, a small C test program that shows what exactly
    fails will be nice.
    
    > 3) the ownership of the data area is incorrect as shipped (I assume this is
    > rpm-specific). On my RH5.0 machine, which is a VAResearch system with Linux/Postgres
    > preinstalled, the data area was owned by root, and the backend cannot start up. If
    > the ownership is changed to the postgres account then the backend starts.
    
    I think that is a VAResearch thing. The package definitely installs the
    /var/lib/pgsql directory owned by postgres account.
    
    > Thanks for building a new RPM. I'll try it at work on my production machine tomorrow.
    > Also, we will have new documentation in v6.3, including html and hardcopy, and you
    > will want to repackage that too. Look in the doc directory (in a day or two; I'm
    > still building the docs and haven't committed anything yet to the source tree).
    
    I am still waiting to find out a way to get cvs read-only access to the
    postgres sources. Downloading a full snapshot evey other day is not my
    favorite game. Especially when a nice shell script can take care of
    automatically generating new rpms every day... :-)
    
    Best wishes,
    
    Cristian
    --
    ----------------------------------------------------------------------
    Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     UNIX is user friendly. It's just selective about who its friends are.
    
    
    
    
    
  6. Re: [HACKERS] Re: Postgresql broken

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-01T16:09:56Z

    > > The test is to start up psql and try
    > >
    > >   select '$1.00'::money;
    > >
    > > which fails. I believe this works on other platforms, and I distinctly recall getting
    >
    > That is true, it fails. However, if you could point to me where exactly
    > something is going wrong I could try and have a look at it. I don't really
    > feel like digging into postgresql source to see which functions are at
    > fault. A small C test program will be nice.
    
    Did you receive my mail dated 1998-02-28 03:02UTC? It contained a very small test program
    which (I believe) illustrates the problem. I've now modified it by dropping the relevant
    Postgres "money" support code straight into it; the new version is enclosed below. Just do
    
      golem> make testlocale
      cc     testlocale.c   -o testlocale
    
    To try it out. It _may_ just be illustrating my lack of understanding of the locale
    support code in Unix, but I'm pretty sure this works on other platforms (and used to work
    on an older - 3.03? 4.0? 4.1? - RH installation).
    
    > > 2) pre-glibc2.0.7 has rounding bugs which cause odd results in some date/time
    > > routines. The test is to try
    > >
    > >   select '4 hours'::timespan;
    >
    > Yepp, it fails.
    
    Dwight reported success when upgrading to a newer glibc but I didn't see a change when
    trying the glibc in your home directory area. Oliver (I think??) reported success with
    Debian with a newer glibc, so perhaps things are fixed and I just didn't do the right
    things to have the machine use the new library.
    
    > > which will return '3 hours 59 mins 60 secs' on a machine with problems. We have
    > > reports from someone running Debian that glibc2.0.7-pre1 (?) fixes the problem. Any
    > > idea on when glibc2.0.7 might be available?
    >
    > the 2.0.7pre1 is available. However, if the debian folks fixed this
    > problem, I can tell you that their patch didn't made it so far in the
    > glibc source tree. Again, a small C test program that shows what exactly
    > fails will be nice.
    
    OK. I'll work on it and try getting it to you soon. As I recall, it is problems with
    rounding behavior in one of the math functions (maybe modf()??). Anyway, will let you
    know.
    
    > > 3) the ownership of the data area is incorrect as shipped (I assume this is
    > > rpm-specific). On my RH5.0 machine, which is a VAResearch system with Linux/Postgres
    > > preinstalled, the data area was owned by root, and the backend cannot start up. If
    > > the ownership is changed to the postgres account then the backend starts.
    >
    > I think that is a VAResearch thing. The package definitely installs the
    > /var/lib/pgsql directory owned by postgres account.
    
    OK.
    
    > > Thanks for building a new RPM. I'll try it at work on my production machine tomorrow.
    > > Also, we will have new documentation in v6.3, including html and hardcopy, and you
    > > will want to repackage that too. Look in the doc directory (in a day or two; I'm
    > > still building the docs and haven't committed anything yet to the source tree).
    >
    > I am still waiting to find out a way to get cvs read-only access to the
    > postgres sources. Downloading a full snapshot evey other day is not my
    > favorite game. Especially when a nice shell script can take care of
    > automatically generating new rpms every day... :-)
    
    We are using CVSup. I built a static version on RH4.2 and placed it on
    
      ftp://postgresql.org/pub/CVSup/cvsup-15.2-client-linux-static.tar.gz
    
    There is a non-static image also, but it probably requires some Modula-3 libraries. Hey,
    that brings up something: would you be interested in a Modula-3 rpm? It would make
    installing CVSup much easier, since I wouldn't have to do the static library thing.
    
    Actually, I'd be willing to build the rpm (or at least the source rpm) or even better help
    set up someone at RH, but I don't know much about rpm building and have been working so
    much on Postgres that I really don't want to start from scratch on figuring it out.
    
    I found that it built fairly easily, but it takes 200MB (!!) to do the build. The
    installation footprint is much smaller. It's a nice environment, and apparently let John
    Polstra, the CVSup developer, do his project fairly easily.
    
    Talk to you soon...
    
                                                 - Tom