Thread: Postgresql 7.1.2
Howdy- saw your e-mail in the postgresql install file, hope you don't mind me writing. Postgresql compiles and runs fine- but the database directories are named by numbers, not by names- which ain't how it is on my linux boxes (nor how its described in the pgsql doc) my posgres user has its home directory set at /private/var/database/postgres data dir is ~/data osx% ls -al data/base/ total 6 drwx------ 4 postgres postgres 1024 Jun 8 23:09 . drwx------ 5 postgres postgres 1024 Jun 8 23:09 .. drwx------ 2 postgres postgres 2048 Jun 8 23:09 1 drwx------ 2 postgres postgres 2048 Jun 8 23:09 18719 osx% That 1 should be a template1 the contents of that directory 1 are also screwed up- osx% ls -al data/base/1/ |tail -10 -rw------- 1 postgres postgres 8192 Jun 8 23:09 17228 -rw------- 1 postgres postgres 0 Jun 8 23:09 17231 -rw------- 1 postgres postgres 8192 Jun 8 23:09 17243 -rw------- 1 postgres postgres 0 Jun 8 23:09 17246 -rw------- 1 postgres postgres 8192 Jun 8 23:09 17258 -rw------- 1 postgres postgres 0 Jun 8 23:09 17261 -rw------- 1 postgres postgres 8192 Jun 8 23:09 17273 -rw------- 1 postgres postgres 8192 Jun 8 23:09 17276 -rw------- 1 postgres postgres 16384 Jun 8 23:09 17288 -rw------- 1 postgres postgres 4 Jun 8 23:09 PG_VERSION osx% from my linux box- [root@athlon /root]# ls -al /var/lib/pgsql/data/base/template1/ |tail -10 -rw------- 1 postgres postgres 0 Jan 5 03:32 pg_tables -rw------- 1 postgres postgres 8192 Jan 5 03:32 pg_trigger -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_trigger_tgconstrname_index -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_trigger_tgconstrrelid_index -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_trigger_tgrelid_index -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_type -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_type_oid_index -rw------- 1 postgres postgres 16384 Jan 5 03:32 pg_type_typname_index -rw------- 1 postgres postgres 0 Jan 5 03:32 pg_user -rw------- 1 postgres postgres 0 Jan 5 03:32 pg_views [root@athlon /root]# I can create a test databse and connect no problem- everything seems to work- but something is obviously not quite right... have any clue as to what is going on? -=- ./configure --prefix=/usr/local \ --sysconfdir=/private/etc \ --with-openssl=/usr/local \ --with-CXX \ --with-odbc \ --enable-syslog \ --disable-shared path for building is /usr/bin:/bin:/usr/sbin:/sbin I don't have any non apple utilities installed in those directories (except for newer sudo with the buffer overflow fix). The openssl I'm building against is 0.9.6a built statically from openssl.org but I really don't think that's the issue. Have any idea what's going on? I haven't tried building from CVS yet (my experience has been cvs builds tend to be more problematic on Darwin than, say, Linux...) OS X Release Candidate that was sent to ADC members, updated to 10.0.3 Beige G3 (333MHz/256) UFS install. Thanks for any suggestions... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Michael A. Peters http://24.5.29/77/OSX-Darwin/
mpeters@mac.com writes:
> Howdy- saw your e-mail in the postgresql install file, hope you don't
> mind me writing.
You must have missed
Note: If you are having problems with the installation on a
supported platform, please write to <pgsql-bugs@postgresql.org> or
<pgsql-ports@postgresql.org>, not to the people listed here.
;-)
> Postgresql compiles and runs fine- but the database directories are
> named by numbers, not by names-
This is new in 7.1.
> which ain't how it is on my linux boxes
> (nor how its described in the pgsql doc)
If you can still find that reference in the 7.1 docs, please point it out
so it can be fixed.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Sat, 9 Jun 2001 12:01:40 +0200 (CEST) Peter Eisentraut <peter_e@gmx.net> wrote: > mpeters@mac.com writes: > > > Howdy- saw your e-mail in the postgresql install file, hope you don't > > mind me writing. > > You must have missed > > Note: If you are having problems with the installation on a > supported platform, please write to <pgsql-bugs@postgresql.org> or > <pgsql-ports@postgresql.org>, not to the people listed here. > > ;-) Yes- I did miss that. I didn't assume he would answer, though- I always try to cc a user list when I e-mail a developer, but I've actually had good luck with responses from developers. Usually they are either quite friendly, or they choose not to respond. Perhaps the e-mail addresses should be kept private that are in that file if they don't want them contacted- but that's a different issue and doesn't warrant discussion except among those people and postgresql. > > > Postgresql compiles and runs fine- but the database directories are > > named by numbers, not by names- > > This is new in 7.1. > > > which ain't how it is on my linux boxes > > (nor how its described in the pgsql doc) > > If you can still find that reference in the 7.1 docs, please point it out > so it can be fixed. I was referring to the postgresql book, and the fact that this change (which seems major to me) isn't referenced in the Changelog (which doesn't seem to have anything from 7.0 to 7.1), install file, or whatever. ---------------------------- [root@osx ChangeLogs]# grep -i "template1" * ChangeLog-7.1beta4-to-7.1beta5: that any installation-local cruft in template1 will not mess up the [root@osx ChangeLogs]# [root@osx postgresql-7.1.2]# grep -i "template" README [root@osx postgresql-7.1.2]# [root@osx postgresql-7.1.2]# grep -i "template" INSTALL /usr/local/pgsql/bin/psql -d template1 -f outputfile [root@osx postgresql-7.1.2]# [root@osx postgresql-7.1.2]# grep -i "template" * 2> /dev/null |grep -v "^config" HISTORY:Modify pg_dump to better handle user-defined items in template1 (Philip) HISTORY:Allow CREATE DATABASE to specify template database (Tom) HISTORY:New template0 database that contains no user additions (Tom) HISTORY:New --template option to createdb HISTORY:Configure matches template/.similar entries better(Tom) HISTORY:This will need to be done to every existing database, including template1. HISTORY:new OS-specific template files(Marc) INSTALL:/usr/local/pgsql/bin/psql -d template1 -f outputfile Binary file doc matches Binary file src matches [root@osx postgresql-7.1.2]# ------------------------------ On linux I run postgresql 7.0.3- which isn't that old. Won't update till I need to- perhaps this change needs to be mentioned in the ChangeLog or Install file (or the FAQ) since it has a big impact on startup scripts that look for template1 in the ~/data/base/ directory to determine wether or not postgresql has been properly initiated. Some people's boot start script will re-initiate if [ ! -d ~/data/base/template1 ] not everyone updates via rpm... > > -- > Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter > -- -=-=-=-=-=-=-=-=-=-=-=-=- Michael A. Peters http://24.5.29.77/
Michael A. Peters writes: > Perhaps the e-mail addresses should be kept private that are in that file if > they don't want them contacted- but that's a different issue and doesn't warrant > discussion except among those people and postgresql. I guess it's okay to Cc: people, but the problem was mostly that mail didn't get to the lists at all. Never mind, though, I was a bit cynical. > I was referring to the postgresql book, The available book was finished before 7.1 came out. > and the fact that this change (which > seems major to me) isn't referenced in the Changelog (which doesn't seem to > have anything from 7.0 to 7.1), install file, or whatever. The HISTORY file has: Store tables as files named by OID (Vadim) The ChangeLog files are mostly nonsense, IMHO. > On linux I run postgresql 7.0.3- which isn't that old. > Won't update till I need to- perhaps this change needs to be mentioned in > the ChangeLog or Install file (or the FAQ) since it has a big impact on > startup scripts that look for template1 in the ~/data/base/ directory to > determine wether or not postgresql has been properly initiated. What happens in the data directory was always an internal matter, except for the PG_VERSION file perhaps. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
what does the element PGDG in an rpm filename, e.g., postgresql-test-7.1.2-2.PGDG.i386.rpm, allude to? PostGreSQL Development Group? What does it mean? I'm trying to get a compete collection of the 7.1.2 binary rpms but have discovered many of the ftp mirrors aren't synched yet. Also many of the mirrors are refusing logins. I did find a responsive mirror in thailand, but the rpms all carry the "PGDG" tag. Can anyone shed some light on this? tjm
On Sat, 9 Jun 2001, Tim Mickol wrote: > what does the element PGDG in an rpm filename, e.g., > postgresql-test-7.1.2-2.PGDG.i386.rpm, allude to? > PostGreSQL Development Group? What does it mean? > > I'm trying to get a compete collection of the 7.1.2 binary rpms but have > discovered many of the ftp mirrors aren't synched yet. > Also many of the mirrors are refusing logins. I did find a responsive > mirror in thailand, but the rpms all carry the "PGDG" tag. > > Can anyone shed some light on this? Post Gresql's Damn Good ? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Saturday 09 June 2001 20:53, Tim Mickol wrote: > what does the element PGDG in an rpm filename, e.g., > postgresql-test-7.1.2-2.PGDG.i386.rpm, allude to? > PostGreSQL Development Group? What does it mean? PostgreSQL Global Development Group. Since all the distributors want to use the plain unadorned release number, I needed a way to make sure people could distinguish between the 'official' PostgreSQL.org RPMset and the distributors' sets -- which can be dramatically different. The Polish(ed) Linux Distribution, in particular, has a completely different RPMset; Connectiva has their own differences; SuSE is fairly different; but Red Hat and Mandrake are more based on this set (which is in turned based on Thomas Lockhart's set for 6.5, which is in turn based on what Red Hat had developed for quite a while). To have five different RPMset's all claiming to be 'postgresql-7.1.2-1' is IMHO too much, particularly when you use rpmfind.net's resources to search for updated versions. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > On Saturday 09 June 2001 20:53, Tim Mickol wrote: > > what does the element PGDG in an rpm filename, e.g., > > postgresql-test-7.1.2-2.PGDG.i386.rpm, allude to? > > PostGreSQL Development Group? What does it mean? > > PostgreSQL Global Development Group. There shouldn't be a dot in '2.PGDG'. > To have five different RPMset's all claiming to be 'postgresql-7.1.2-1' is > IMHO too much, particularly when you use rpmfind.net's resources to search > for updated versions. That's why there is a Packager field in the information header. It is a bit misdesigned, I agree, but making your set with a cryptic name won't exactly underline its "official" status. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
The ability to easily identify builds by packager is a great idea, but in practice, I discovered last night (earlier this morning) that using such a filename construct apparently confuses rpm-oriented applications like RedHats kickstart, which has expectations about the composition of the "." delimited elements in an rpm filename. I think I'll just have to quell impatience and laziness and rely on rpm -qPi or rpm -qPil <package> tjm -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Peter Eisentraut Sent: Sunday, June 10, 2001 2:32 AM To: Lamar Owen Cc: Tim Mickol; pgsql-general@postgresql.org Subject: Re: [GENERAL] PGDG? Lamar Owen writes: > On Saturday 09 June 2001 20:53, Tim Mickol wrote: > > what does the element PGDG in an rpm filename, e.g., > > postgresql-test-7.1.2-2.PGDG.i386.rpm, allude to? > > PostGreSQL Development Group? What does it mean? > > PostgreSQL Global Development Group. There shouldn't be a dot in '2.PGDG'. > To have five different RPMset's all claiming to be 'postgresql-7.1.2-1' is > IMHO too much, particularly when you use rpmfind.net's resources to search > for updated versions. That's why there is a Packager field in the information header. It is a bit misdesigned, I agree, but making your set with a cryptic name won't exactly underline its "official" status. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
On Sunday 10 June 2001 05:32, Peter Eisentraut wrote: > Lamar Owen writes: > There shouldn't be a dot in '2.PGDG'. Why? 'Official' Red Hat packages sometimes come out with dots in the release number -- for example, compat-libstdc++-6.2-2.9.0.14 as installed in RedHat 7.1. And the 'unofficial' Rawhide is replete with decimal release numbers. If a software package that claims to be RPM-compatible can't handle a fully supported (by RPM itself) release name, well, the package's authors need to take a look at their code. Of course, it doesn't matter to me either way other than the readability improvement of using the dot, so I'm not going to make it a religious issue. > > To have five different RPMset's all claiming to be 'postgresql-7.1.2-1' > > is IMHO too much, particularly when you use rpmfind.net's resources to > > search for updated versions. > That's why there is a Packager field in the information header. It is a > bit misdesigned, I agree, but making your set with a cryptic name won't > exactly underline its "official" status. But that field doesn't show up in an ftp directory listing. As long as our set is 'different' in name, I'm fine - but it needs to be where not only can _we_ recognize the set, distributors can as well, and properly redirect questions to us (or me) for that set. Nor does the field show up on rpmfind.net's index. The least amount of trouble, the better, IMHO. Why should I require the user to click on every single 'postgresql-7.1.2-2.i386.rpm' link on rpmfind justto find our set? No, our set (when I begin uploading to Red Hat's contrib server again) needs to stand out in the list. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11