Обсуждение: First 6.5 RPMs
Hi. I've posted RPMs for Postgres v6.5 at ftp://postgresql.org/pub/RPMS.beta/postgresql*.rpm and ftp://postgresql.org/pub/SRPMS.beta/postgresql*.rpm The "beta" in the directory name is for the RPM itself, not Postgres, and once one or a few people confirm that these RPMs do the Right Thing then I'll change the directories to be RPMS/ and SRPMS/. I've included Tom Lane's patches for building with shared libraries and for fixing an rtree indexing problem. Changes from previous RPMs built by Red Hat: 1) All available interfaces are built and packaged. These include C, C++, tcl, perl, python, ODBC, and Java. 2) The "main package" contains the basic client libraries and apps, and *all* of the documentation. This will allow you to use a remote server, and to read about everything, by installing one basic package. 3) The backend server is in a separate package "postgresql-server". In previous RPMs the server was in the main package, and the clients were in "postgresql-clients", but the clients package was required by all of the other packages. I think the new organization behaves better for someone who just looks at file names to figure out what they need to do (that's just about everyone ;). Known problems/features to solve later: a) The perl installation should put libraries into architecture-specific areas on the target machine. It doesn't, and the solution probably involves packaging most of the perl source tree into the binary rpm, then building the package on the target. This is not a common way to use RPM. b) The python installation is very specific to python-1.5. The path names are hardcoded, and I'm not sure the best way to make this transparent. Perl has a mechanism for telling you the current library area; don't know if python has something similar. c) Clean up the postgresql.init startup file to make it easier to see how to set typical parameters like DB location. To install and use the packages: i1) If you already have Postgres installed, make sure you do a pg_dumpall on your installation. Use something like pg_dumpall > machine.pg_dumpall For a simple installation, I've found this to be *completely* transparent; much easier than I've heard it was in the past. Then shut down the old server. If you are upgrading from v6.4.2 or earlier, use the "-z" flag with pg_dumpall. i2) Remove any old Postgres RPMs using rpm -e <packagename> postgresql-clients is no longer part of the distro, so that is listed as a "conflict" and you can't just upgrade without removing it first. i3) Install the new RPMs. Use rpm -Uvh <packagenames> i4) The default location for the data area is /var/lib/pgsql/data/. Make sure this is cleaned up or moved aside by renaming it so that you can initialize a new database area. i5) Run initdb. Point to your new database area with something like initdb --pgdata=/var/lib/pgsql i6) Start up your new server. i7) Reload your database. Use something like psql < machine.pg_dumpall i8) Let me know what went wrong ;) Please let me know how it goes, so we can nail the RPM building process for this release. Oh, I built this using a RH5.2 machine, so someone running RH6.0 might want to verify that this installs and works there too. afaik it should be OK, unless the python version number has bumped. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Thomas Lockhart wrote: > > Hi. I've posted RPMs for Postgres v6.5 at > > Please let me know how it goes, so we can nail the RPM building > process for this release. Oh, I built this using a RH5.2 machine, so > someone running RH6.0 might want to verify that this installs and > works there too. afaik it should be OK, unless the python version > number has bumped. I successfully installed them here on one of my Mandrake 5.3 machines. I'm going to let AOLserver bang on that database for the next 72 hours or so -- everything went smoothly. I installed the main package, the devel package (required to build AOLserver's postgres client), and the server package. I will build rh6 rpms this weekend and place them on my server Monday (once I reenable anon-ftp on my utility box), as I don't have a 6.0 box here to build on, yet. Thanks for the work! Lamar Owen WGCR Internet Radio
Lamar Owen wrote: > > I successfully installed them here on one of my Mandrake 5.3 machines. Great! > I'm going to let AOLserver bang on that database for the next 72 hours > or so -- everything went smoothly. I installed the main package, the > devel package (required to build AOLserver's postgres client), and the > server package. I'm interested in how the other interface packages installed. Perhaps you can install the tcl package and fire up pgaccess (should be trivial)? > I will build rh6 rpms this weekend and place them on my server Monday > (once I reenable anon-ftp on my utility box), as I don't have a 6.0 box > here to build on, yet. Can you try installing the rpms on your RH6.0 box before you build and install them yourself? I'm interested in whether they behave (I think they should...). Also, before we post too many variants, perhaps we can work out the portability issues with perl and python; then we can probably rely on a single solid build on a fresh machine like your RH6.0 box. Thanks for the help. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Thomas Lockhart wrote: > I'm interested in how the other interface packages installed. Perhaps > you can install the tcl package and fire up pgaccess (should be > trivial)? I did -- and now I'm going to make pgaccess and the tcl client part of my standard toolkit! I hadn't had time before to try out pgaccess -- but, it seems to work fine, once I remembered to set "-i" on the postmaster line. BTW, while we're on that subject, might I suggest that, since the default pg_hba.conf is for localhost only access, even over tcp/ip, the "-i" is made the default in the postgresql init script?? It seems that several programs need it -- pgaccess included. > Can you try installing the rpms on your RH6.0 box before you build and > install them yourself? I'm interested in whether they behave (I think > they should...). Hmmm... I'll try that first -- the problem is going to be rpms built against glibc 2.0.7 (RH52) running against glibc 2.1 (RH6) I'll blow in the binaries first -- if there are oddities, I'll build fresh glibc2.1 rpms and see what comes out. I will note that I have the compat-libs installed. > Also, before we post too many variants, perhaps we can work out the > portability issues with perl and python; then we can probably rely on > a single solid build on a fresh machine like your RH6.0 box. Those two are going to be fun. I'll let you know the results of my RedHat 6 test at home. Lamar Owen WGCR Internet Radio
Hi, I've encountered a strange behavior of the VACUUM ANALYZE command. It seems that this command works only if the size of a text field does not exceed approximately 4050 bytes! So the real limit on tuple size is a half of the max tuple size. I've checked this effect on Postgres 6.4.2 (Sparc Solaris 2.5.1) and Postgres 6.5 (SUSE 6.1 Linux, kernel 2.2.5). Is this a bug or known feature? The python script used to reproduce this problem and results for v6.4.2 and v6.5 are follows. Regards, Mikhail =================================================================== #! /usr/bin/env python import sys, pg con = pg.connect('test', '', 5432, None, None) try: con.query("CREATE TABLE tmp (t text)") except: pass for i in range(100) : s = 'X'*(4050 +i) print "size= %d" % len(s) con.query("DROP TABLE tmp") con.query("CREATE TABLEtmp (t text)") con.query("INSERT INTO tmp (t) VALUES ('%s')" % s) try: con.query("VACUUM ANALYZE tmp") exceptpg.error,msg: print msg sys.exit() print "OK" =================================================================== SunOS luc1 5.5.1 Generic_105428-01 sun4u sparc SUNW,Ultra-5_10 python vacuum_chk.py size= 4050 size= 4051 size= 4052 size= 4053 size= 4054 size= 4055 size= 4056 size= 4057 ERROR: Tuple is too big: size 8184 =================================================================== Linux luc2 2.2.5 #4 Tue Apr 13 16:51:36 MEST 1999 i686 unknown vacuum_chk.py size= 4050 size= 4051 size= 4052 size= 4053 size= 4054 size= 4055 size= 4056 size= 4057 size= 4058 size= 4059 size= 4060 size= 4061 size= 4062 size= 4063 size= 4064 size= 4065 ERROR: Tuple is too big: size 8188 ===================================================================