Обсуждение: 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
===================================================================