Thread: psql -l
in the old days (7.0.3) i could list databases via
psql -l
but these days (7.1) i must
psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
probably because of some fuxnored setting. but which?
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
will trillich writes: > in the old days (7.0.3) i could list databases via > > psql -l > > but these days (7.1) i must > > psql -l [-d] nameOfADatabaseFromPreordainedKnowledge > > probably because of some fuxnored setting. but which? Evidence please? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
will trillich <will@serensoft.com> writes:
> in the old days (7.0.3) i could list databases via
> psql -l
> but these days (7.1) i must
> psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
> probably because of some fuxnored setting. but which?
Sounds like you've got pg_hba.conf set to disallow connections to
template1, which is what psql tries to connect to when executing
a plain "psql -l".
regards, tom lane
> in the old days (7.0.3) i could list databases via > > psql -l > > but these days (7.1) i must > > psql -l [-d] nameOfADatabaseFromPreordainedKnowledge > > probably because of some fuxnored setting. but which? psql -l works fine for me... 7.1.2. Does it return an error or just not work? Greg
> will trillich <will@serensoft.com> writes: > > in the old days (7.0.3) i could list databases via > > psql -l > > but these days (7.1) i must > > psql -l [-d] nameOfADatabaseFromPreordainedKnowledge > > probably because of some fuxnored setting. but which? > > Sounds like you've got pg_hba.conf set to disallow connections to > template1, which is what psql tries to connect to when executing > a plain "psql -l". Ewe, I never realized the problems with disabling template1 connections. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
On Tue, Jul 17, 2001 at 04:34:29PM -0400, Tom Lane wrote:
> will trillich <will@serensoft.com> writes:
> > in the old days (7.0.3) i could list databases via
> > psql -l
> > but these days (7.1) i must
> > psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
> > probably because of some fuxnored setting. but which?
>
> Sounds like you've got pg_hba.conf set to disallow connections to
> template1, which is what psql tries to connect to when executing
> a plain "psql -l".
here's the totality of pg_hba.conf (sans comments):
# grep -v '#' /etc/postgresql/pg_hba.conf | uniq
local all trust
host all 127.0.0.1 255.0.0.0 trust
host all 192.168.1.0 255.255.255.0 trust
host all 0.0.0.0 0.0.0.0 crypt
$ psql -V
No database specified
$ psql -V template0
psql (PostgreSQL) 7.1
contains readline, history, multibyte support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
curiouser and curiouser.
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
On Tue, Jul 17, 2001 at 09:26:02PM +0200, Peter Eisentraut wrote:
> will trillich writes:
>
> > in the old days (7.0.3) i could list databases via
> >
> > psql -l
> >
> > but these days (7.1) i must
> >
> > psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
> >
> > probably because of some fuxnored setting. but which?
>
> Evidence please?
this was 7.0.3, as it'll tell you:
$ psql -V
psql (PostgreSQL) 7.0.3
contains readline, history, multibyte support
Portions Copyright (c) 1996-2000, PostgreSQL, Inc
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
$ psql -l
List of databases
Database | Owner | Encoding
-----------+----------+----------
admin | rdt | LATIN1
agf | will | LATIN1
camp | rdt | LATIN1
ed | will | LATIN1
gunk | will | LATIN1
puz | will | LATIN1
secsed | will | LATIN1
template1 | postgres | LATIN1
testorama | will | LATIN1
tharp | rdt | LATIN1
tips | will | LATIN1
will | will | LATIN1
(12 rows)
but with v 7.1 i get
$ psql -V
No database specified
$ psql -l
No database specified
$ psql -V mydb
psql (PostgreSQL) 7.1
contains readline, history, multibyte support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
will trillich <will@serensoft.com> writes:
> $ psql -V
> No database specified
This seems awfully fishy, since (a) there is no such error message
anywhere in 7.1, and (b) I don't get that behavior out of 7.1:
$ ~postgres/version71/bin/psql -V
psql (PostgreSQL) 7.1.2
contains readline, history support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
$
Perhaps you are invoking psql through some kind of wrapper script that
is doing the wrong thing?
regards, tom lane
On Wed, Jul 18, 2001 at 11:57:35AM -0400, Tom Lane wrote:
> will trillich <will@serensoft.com> writes:
> > $ psql -V
> > No database specified
>
> This seems awfully fishy, since (a) there is no such error message
> anywhere in 7.1, and (b) I don't get that behavior out of 7.1:
>
> $ ~postgres/version71/bin/psql -V
> psql (PostgreSQL) 7.1.2
> contains readline, history support
> Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
> Portions Copyright (c) 1996 Regents of the University of California
> Read the file COPYRIGHT or use the command \copyright to see the
> usage and distribution terms.
> $
>
> Perhaps you are invoking psql through some kind of wrapper script that
> is doing the wrong thing?
i'm wondering now if this may be a debian packaging mishap...
or maybe i've got psql v7.0.3 trying to work with postmaster
7.1, but that doesn't seem likely...
at any rate -- maybe this session with 'strings' might help you
see identify what's goofing up here.
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Script started on Wed Jul 18 12:21:42 2001
$ which psql
/usr/bin/psql
$ ls -l `which psql`
lrwxrwxrwx 1 root root 10 Jul 1 22:28 /usr/bin/psql -> pg_wrapper
$ psql -V
No database specified
$ psql -V ed
psql (PostgreSQL) 7.1
contains readline, history, multibyte support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
$ strings `which psql` | grep -i speci
No database specified
$ strings `which psql` | wc -l
74
$ strings `which psql`
/lib/ld-linux.so.2
__gmon_start__
libc.so.6
strcpy
getopt_long
getenv
pclose
malloc
optarg
popen
rindex
fprintf
__deregister_frame_info
getdelim
optind
setenv
__strdup
execv
strncat
memset
stderr
exit
_IO_stdin_used
__libc_start_main
__register_frame_info
GLIBC_2.1
GLIBC_2.0
PTRh
Vj=3DWj
/usr/lib/postgresql/bin/
/var/lib/postgres/data
PGDATA
/usr/lib/postgresql/lib
PGLIB
5432
PGPORT
pg_wrapper
pg_wrapper cannot be run as itself, but only through a link
whose name is that of the real program to be run.
psql
help
no-psqlrc
expanded
password
version
variable
username
table-attr
tuples-only
single-line
single-step
record-separator
pset
port
output
list
html
host
field-separator
file
echo-hidden
echo-queries
dbname
command
no-align
echo-all
aAc:d:Eef:F:h:Hlo:p:P:qR:sStT:uU:v:VWxX?
PGDATABASE
Could not execv %s
No database specified
env - /usr/lib/postgresql/bin/readpgenv
Could not run %s
Unexpected input from %s:
%s=3D%s
$ exit
Script done on Wed Jul 18 12:21:53 2001
On Wednesday 18 July 2001 11:57, Tom Lane wrote: > will trillich <will@serensoft.com> writes: > > $ psql -V > > No database specified > This seems awfully fishy, since (a) there is no such error message > anywhere in 7.1, and (b) I don't get that behavior out of 7.1: > Perhaps you are invoking psql through some kind of wrapper script that > is doing the wrong thing? Debian, perhaps? From the Debian patchfile: ( http://non-us.debian.org/debian-non-US/pool/non-US/main/p/postgresql/postgresql_7.1.2-1.diff.gz ) +Debian-specific features +======================== + +There are certain differences between the Debian version of PostgreSQL +and the upstream version. There are two reasons for this. First, +because Debian policy requires certain things to be done in a manner +different from that used by the upstream developers, and second, because +I perceive a difference between a piece of software that is put onto +a machine by an ordinary user and one that is installed, as part of a +distribution, by the system administrator. + +1. Environment variables: Debian forbids packages to depend on users' + setting environment variables. For this reason, certain front-end + programs, especially psql, are run through a wrapper that sets up + the environment. + +2. Default database: the upstream version defaults to a database whose + name is the same as the name of the PostgreSQL user who is trying to + access it. I do not think this is appropriate to a distribution, so + in Debian, the database must be specified on the command line or in + the environment variable PGDATABASE. + +3. Initialising the postmaster: the upstream version uses a program called + pg_ctl, that was introduced at release 7.0, to start up and stop the + postmaster. I do not feel that this sits very comfortably with + Debian's way of starting backend processes, so I have continued to use + the procedure I developed for previous versions, whereby + /etc/init.d/postgresql calls postgresql-startup or start-stop-daemon. + I will be borrowing nice features from pg_ctl to incorporate in the + init.d script. + +4. Initial environment: Debian stores its setup files in /etc/postgresql. + These files are postmaster.conf, pg_hba.conf and postgresql.env, and any + files referenced by pg_hba.conf. They are self-documented, so you are + advised to leave the coments alone if you edit them. Where necessary, + there are symbolic links to the locations where the upstream code + expects to find them. + +5. Location of socket: in previous versions the socket file was located + in /tmp/. It has now been moved to /var/run/postgresql/ so as to avoid + problems with packages such as tmpreaper and to be more consistent + with Debian policy. This location can be altered by setting + UNIX_SOCKET_DIRECTORY in postgresql.conf. + +6. Unix socket authentication is provided (authentication type "peer"). + This works just like ident, but for Unix sockets; this provides a more + secure method of authentication than ident, and does not require + administrators to run identd on their servers. This authentication + method has been submitted to the upstream developers, but is not + currently part of the upstream release. + This excerpt from the file README.Debian. The error message itself is being issued by the Debian 'pg_wrapper' program (see the pg_wrapper source embedded in the patchfile starting at line 5434 -- the error message itself is at line 5646 in the patchfile). I can sympathize with Oliver here -- distribution policy can be a pain to deal with, although Red Hat's policy isn't apparently as strict as Debian's. I also sympatchize and agree with Oliver's statement about differences between packages that are installed by a user in /usr/local and packages installed by the system administrator as part of an operating system. We're not, eh, 'distribution-friendly' in reality -- although Peter's work on the build system really helped the RPM side of things. The 'traditional PostgreSQL installation' is more 'user-install'-centric -- which is OK, as long as everybody knows what the packagers are doing... :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
What is not appropriate is that we are getting error reports for programs we didn't write! > On Wednesday 18 July 2001 11:57, Tom Lane wrote: > > will trillich <will@serensoft.com> writes: > > > $ psql -V > > > No database specified > > > This seems awfully fishy, since (a) there is no such error message > > anywhere in 7.1, and (b) I don't get that behavior out of 7.1: > > > Perhaps you are invoking psql through some kind of wrapper script that > > is doing the wrong thing? [ Much pontificating skipped.] -- Bruce Momjian | http://candle.pha.pa.us pgman@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
On Wednesday 18 July 2001 15:30, Lamar Owen wrote:
> Debian's. I also sympatchize and agree with Oliver's statement about
^^^^^^^^^^^
Freudian slip... ROTFL....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Wednesday 18 July 2001 16:30, Bruce Momjian wrote: > What is not appropriate is that we are getting error reports for > programs we didn't write! Which is why I believe that Red Hat's 'relabeling' is a Good Thing -- _they_ will get bug reports for 'Red Hat Database' -- then _they_ can contact the hackers list after verifying that it isn't their 'modifications' causing the problem. I really try to make the RPM's patching minimal -- directory paths, a README, migration helper scripts, and the initscript are the only 'enhancements' I provide. And I try to field any reports I see on the list.... However, Oliver is a part of 'we' isn't he? > [ Much pontificating skipped.] Interesting choice of words.... I wasn't intending to sound authoritarian.... or religious. Sorry if I did sound pontifical. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Wednesday 18 July 2001 18:03, Bruce Momjian wrote: > The strange part is that we are running around trying to figure out if > it is a bug and no one knows that Debian has modified it. While I understand Oliver's reasons for having the Debian stuff on the debian server, I believe it would be appropriate to have the patchfile and the various Debian README's available on the main postgresql site. It was a hunch that sent me looking there -- I had read the Debian patchfile before (about the 'peer' authentication deal), and apparently my subconscious picked up on it. > The Red Hat stuff isn't a problem because you recoginize it as such. The RPM has a rather distinctive footprint, yes.... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> On Wednesday 18 July 2001 16:30, Bruce Momjian wrote: > > What is not appropriate is that we are getting error reports for > > programs we didn't write! > > Which is why I believe that Red Hat's 'relabeling' is a Good Thing -- _they_ > will get bug reports for 'Red Hat Database' -- then _they_ can contact the > hackers list after verifying that it isn't their 'modifications' causing the > problem. > > I really try to make the RPM's patching minimal -- directory paths, a README, > migration helper scripts, and the initscript are the only 'enhancements' I > provide. And I try to field any reports I see on the list.... > > However, Oliver is a part of 'we' isn't he? The strange part is that we are running around trying to figure out if it is a bug and no one knows that Debian has modified it. The Red Hat stuff isn't a problem because you recoginize it as such. > > [ Much pontificating skipped.] > > Interesting choice of words.... I wasn't intending to sound authoritarian.... > or religious. Sorry if I did sound pontifical. No, it was the Debian guy who sounded funny. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Lamar Owen <lamar.owen@wgcr.org> writes:
> On Wednesday 18 July 2001 18:03, Bruce Momjian wrote:
>> The strange part is that we are running around trying to figure out if
>> it is a bug and no one knows that Debian has modified it.
> While I understand Oliver's reasons for having the Debian stuff on the
> debian server, I believe it would be appropriate to have the patchfile
> and the various Debian README's available on the main postgresql site.
ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree
(perhaps in /contrib, perhaps somewhere else, but anyway in the tree).
Had I been able to find that "No database specified" string by grepping
the sources, I'd have been much less mystified. Likewise for the "peer"
question a week or two back, and the questions we sometimes get about
the behavior of startup scripts that aren't even part of our tarball.
This sort of thing is going to keep coming up, so we might as well admit
that we need to know what is in the RPMs.
Oliver, Lamar, what say you?
regards, tom lane
On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > While I understand Oliver's reasons for having the Debian stuff on the > > debian server, I believe it would be appropriate to have the patchfile > > and the various Debian README's available on the main postgresql site. > ISTM that it'd be a good thing if current versions of all the add-on > source files for both Debian and RedHat RPMs were part of our CVS tree > (perhaps in /contrib, perhaps somewhere else, but anyway in the tree). > Had I been able to find that "No database specified" string by grepping > the sources, I'd have been much less mystified. Likewise for the "peer" > question a week or two back, and the questions we sometimes get about > the behavior of startup scripts that aren't even part of our tarball. Deja vu... didn't we have this discussion a month or two back?? :-) ( http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread ) I'm all for it for the RPM's, at least, if others are game. We left off with the question of where it would best be stored.... There is, in fact, an outstanding issue with the RPM initscript that I'm still working on -- the 'sometimes I get a failure that isn't really a failure' deal....I can't reproduce it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote: >> ISTM that it'd be a good thing if current versions of all the add-on >> source files for both Debian and RedHat RPMs were part of our CVS tree > Deja vu... didn't we have this discussion a month or two back?? :-) ( > http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread ) Yeah, we did. You seemed willing, but there was a notable silence from the Debian quarter. regards, tom lane
On Thu, Jul 19, 2001 at 12:11:47AM -0400, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote: > >> ISTM that it'd be a good thing if current versions of all the add-on > >> source files for both Debian and RedHat RPMs were part of our CVS tree > > > Deja vu... didn't we have this discussion a month or two back?? :-) ( > > http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread ) > > Yeah, we did. You seemed willing, but there was a notable silence > from the Debian quarter. There have been discussions in the past on the debian mailing lists about whether it is a good idea for upstream sources to include the debian patch. The gist of it that since debian builds packages based on a pristine source tar ball and a patch, if the patch were upstream, would the patch have to patch its own upstream version? If however they were merely stored in contrib/distributions/patches or some such and there was an understanding that that may not match what is currently available from debian, then I see no problem. -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > It would be nice if someone came up with a certification system that > actually separated those who can barely regurgitate what they crammed over > the last few weeks from those who command secret ninja networking powers.
Tom Lane writes: > ISTM that it'd be a good thing if current versions of all the add-on > source files for both Debian and RedHat RPMs were part of our CVS tree If you want to take the job of keeping these up to date or the job of convincing all the 143 package developers out there to do that... All of these package files are in a CVS tree somewhere (or should be), and I would be happy to provide you with the links I use to poke around them on occasion, but it should not be our job to keep track of the fancies of operating system developers. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Tom Lane writes: > > > ISTM that it'd be a good thing if current versions of all the add-on > > source files for both Debian and RedHat RPMs were part of our CVS tree > > If you want to take the job of keeping these up to date or the job of > convincing all the 143 package developers out there to do that... > > All of these package files are in a CVS tree somewhere (or should be), and > I would be happy to provide you with the links I use to poke around them > on occasion, but it should not be our job to keep track of the fancies of > operating system developers. I am slightly concerned about bloating our CVS tree. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> Deja vu... didn't we have this discussion a month or two back?? :-) ( > http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread ) > > I'm all for it for the RPM's, at least, if others are game. We left off with > the question of where it would best be stored.... > > There is, in fact, an outstanding issue with the RPM initscript that I'm > still working on -- the 'sometimes I get a failure that isn't really a > failure' deal....I can't reproduce it. Let me add that Red Hat is now distributing a different RPM with their Red Hat Database, or at least I think they are. Can someone confirm? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
On Friday 20 July 2001 10:05, Peter Eisentraut wrote: > Tom Lane writes: > > ISTM that it'd be a good thing if current versions of all the add-on > > source files for both Debian and RedHat RPMs were part of our CVS tree > If you want to take the job of keeping these up to date or the job of > convincing all the 143 package developers out there to do that... That would be my job to do for the RPM's, right? :-) I'm already keeping them up -- and I know how to use CVS to do it, having commit access on a couple of other projects. Let me just say on thing about 'our' RPMs -- they are intended as a semi-standard base from which OS distributors may make their own packages, for which they are responsible. A side benefit is that people can grab the latest hopefully-generic RPMset from us if their OS vendor isn't forthcoming with updated packages. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Friday 20 July 2001 11:24, Bruce Momjian wrote: > Let me add that Red Hat is now distributing a different RPM with their > Red Hat Database, or at least I think they are. Can someone confirm? Trond may be able to. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need
> to investigate this more closely....
Seems like that should go into our regular contrib tree.
> The .patch files are system-specific and RPM-specific patches that
> probably are not necessary to be applied to the main tree, as they
> mostly involve paths (particularly for the regression tests), with the
> exception of the s390 patch. I can send these patches to the list
> easily enough -- the s390 patch is also a Red Hat contribution.
Portability patches also seem like they should go into the main sources.
regards, tom lane
Re: RPM source files should be in CVS (was Re: psql -l)
From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Lamar Owen <lamar.owen@wgcr.org> writes: > On Friday 20 July 2001 11:24, Bruce Momjian wrote: > > Let me add that Red Hat is now distributing a different RPM with their > > Red Hat Database, or at least I think they are. Can someone confirm? > > Trond may be able to. The rpms of the Red Hat database are called rhdb, to avoid confusion. -- Trond Eivind Glomsrød Red Hat, Inc.
On Friday 20 July 2001 11:25, Bruce Momjian wrote: > I am slightly concerned about bloating our CVS tree. [lowen@utility pgsql]$ du -s * 4 COPYRIGHT 20 CVS 276 ChangeLogs 4 GNUmakefile.in 124 HISTORY 36 INSTALL 4 Makefile 4 README 4 aclocal.m4 160 config 240 configure 36 configure.in 3520 contrib 7196 doc 4 register.txt 30128 src [lowen@utility pgsql]$ The RPM additions are: 56 contrib-intarray.tar.gz 4 file-lists.tar.gz 180 jdbc7.0-1.1.jar 92 jdbc7.1-1.2.jar 8 migration-scripts.tar.gz 4 postgresql-7.1.plperl.patch 4 postgresql-7.1.s390x.patch 4 postgresql-bashprofile 4 postgresql-dump.1.gz 8 postgresql.init 20 README.rpm-dist 4 rh-pgdump.sh 8 rpm-pgsql-7.1.patch Of which the two jar files are derived from the source and wouldn't be necessary. This totals 124K if I've done my math right. The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need to investigate this more closely.... 'file-lists.tar.gz' may go away if I don't need to support older SuSE distributions. 'migration-scripts.tar.gz' is a packaging of a few scripts used to perform a dump using saved binaries from the previous installation. The .patch files are system-specific and RPM-specific patches that probably are not necessary to be applied to the main tree, as they mostly involve paths (particularly for the regression tests), with the exception of the s390 patch. I can send these patches to the list easily enough -- the s390 patch is also a Red Hat contribution. 'postgresql-bashprofile' is a .bashprofile placed into $PGDATA during RPM installation (and, yes, unless someone goes and changes it the default shell for the 'postgres' user is installed as bash). 'postgresql-dump.1.gz' is a man page for 'postgresql-dump' -- part of the migrations-scripts tarball. 'rh-dump.sh' is another migration script that I really should fold into the migrations-scripts tarball.... Although any of these migration scripts are a mite cantankerous, as a pg_dumpall from 6.5.x to be restored on 7.1.x has been shown to fail in certain instances (documented in the archives). Most noticeable is the '60 minute' problem in 6.5's time types. 7.1.x takes a 6.5 dump a little easier than 7.0 did, though, IME. 'postgresql.init' is the initscript installed into /etc/rc.d/init.d/postgresql. 'README.rpm-dist' tries to document the RPM differences and _why_ there are RPM differences in the first place. While I technically _could_ patch the installed SGML documentation sources to reflect the RPM installation, I have not yet done so. README.rpm-dist is also available for perusal via the website as http://www.postgresql.org/ftpsite/binary/v7.1.2/RPMS/README.rpm-dist linked off of http://www.postgresql.org/sites.html . I'll be happy to document or discuss any of these files with anyone. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> On Friday 20 July 2001 11:25, Bruce Momjian wrote: > > I am slightly concerned about bloating our CVS tree. > The RPM additions are: > 56 contrib-intarray.tar.gz > 4 file-lists.tar.gz > 180 jdbc7.0-1.1.jar > 92 jdbc7.1-1.2.jar > 8 migration-scripts.tar.gz > 4 postgresql-7.1.plperl.patch > 4 postgresql-7.1.s390x.patch > 4 postgresql-bashprofile > 4 postgresql-dump.1.gz > 8 postgresql.init > 20 README.rpm-dist > 4 rh-pgdump.sh > 8 rpm-pgsql-7.1.patch > > Of which the two jar files are derived from the source and wouldn't be > necessary. This totals 124K if I've done my math right. Bag the JAR's and it looks fine. > The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need > to investigate this more closely.... Can you research that? Why are they doing it? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Re: RPM source files should be in CVS (was Re: psql -l)
From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes: > > On Friday 20 July 2001 11:25, Bruce Momjian wrote: > > > I am slightly concerned about bloating our CVS tree. > > The RPM additions are: > > 56 contrib-intarray.tar.gz > > 4 file-lists.tar.gz > > 180 jdbc7.0-1.1.jar > > 92 jdbc7.1-1.2.jar > > 8 migration-scripts.tar.gz > > 4 postgresql-7.1.plperl.patch > > 4 postgresql-7.1.s390x.patch > > 4 postgresql-bashprofile > > 4 postgresql-dump.1.gz > > 8 postgresql.init > > 20 README.rpm-dist > > 4 rh-pgdump.sh > > 8 rpm-pgsql-7.1.patch > > > > Of which the two jar files are derived from the source and wouldn't be > > necessary. This totals 124K if I've done my math right. > > Bag the JAR's and it looks fine. > > > The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need > > to investigate this more closely.... > > Can you research that? Why are they doing it? It's a new one from upstream - it fixed some bugs, AFAIK. -- Trond Eivind Glomsrød Red Hat, Inc.