[SPOOFED] Nothing to see here (was:Re: [GENERAL] I have had enough)
[all content snipped] Spoofed again. Nothing to see here. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] The reasoning behind having several features outside of source?
On Monday 25 October 2004 14:19, [EMAIL PROTECTED] wrote: Why is it that PostgreSQL chooses to have features like replication, fulltext indexing and GIS maintained by others outside of the sourcetree? I'll make the attempt to answer best I can. PostgreSQL's architecture is very open and highly extensible. Several different solutions for these particular pieces have been independently developed, simply because the extensibility API is so flexible. Since they were originally developed outside the main source tree, many have tended to stay outside the main source tree and be maintained by their original developers. This is a result of the extensible design and a certain perlesque TMTOWTDI mindset. Since these features started out that way it is easier for the maintainers and developers of the main source tree to continue that relationship, since it keeps the main source tree cleaner and simpler for those who don't necessarily need the features in question. Further, the main tree's developers might not want to select one particular implementation (such as in replication) over another one, since they might meet different needs of different groups. In particular, there are several replication solutions available, each meeting a different set of needs. But the API used is robust and reliable, making these modules have the potential to be just as robust and reliable as the main source tree. This is a FAQ, but I'm not sure if it is addressed in any of our written FAQ lists. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 7.4.3 Now Available ...
On Friday 18 June 2004 09:21, Robert Treat wrote: I notice we have yet to get a directory for 7.4.3 under /binary, are you planning on putting them up on the ftp server as well? Along those lines is anyone planning on doing a redhat 7.3 build ? I'm running behind on this cycle. Been swamped at work. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] RPM init-script: Why the locale setting?
On Sunday 04 April 2004 10:50 pm, Tom Lane wrote:
Troels Arvin [EMAIL PROTECTED] writes:
In the init-script contained in the RPMs downloadable from the PostgreSQL
site (I checked the one for Fedora), an explicit locale is set before
running initdb. - And the explicit locale is not C.
Only if you don't have a sysconfig file:
# Just in case no locale was set, use en_US
[ ! -f /etc/sysconfig/i18n ] echo LANG=en_US $PGDATA/../initdb.i18n
I agree though that it seems like a bad choice to default to en_US
rather than C. Lamar, any reason why it's like that?
Yes.
A bit of history before I enclose an e-mail from Trond Eivind Glomsrd (former
Red Hat internal PostgreSQL RPMmaintainer) on the subject. I am only
enclosing a single e-mail of an exchange that occurred over a period of a
couple of weeks; I have pretty much whole exchange archived if you want to
read more, although I cannot reveal the whole exchange due to some NDA stuff
in it. Although it might be OK at this point, since that was, after all, 3
years ago.
Back in PostgreSQL 7.1 days, locale settings and the issue of a database being
initdb'ed in one locale and the postmaster starting in another locale reared
up its head. I 'solved' the issue by hardcoding LC_ALL=C in the initscript.
This had the side-effect of making the regression tests pass. Trond wasn't
happy with my choice of C locale, and here is why:
Re: Thought you might find this very interesting.
From: [EMAIL PROTECTED] (Trond Eivind Glomsrd)
To: Lamar Owen [EMAIL PROTECTED]
Lamar Owen [EMAIL PROTECTED] writes:
On Friday 25 May 2001 15:04, you wrote:
Lamar Owen [EMAIL PROTECTED] writes:
I also intend to kill the output from database initialization.
I thought you had, at least in the RedHat 7.1 7.0.3 set.
Yup, but it has started showing up again in PostgreSQL 7.1.x
I need to sync that in with this set.
I've fixed a couple of issues with the inistscript, I'll send it to
you when it's finished even after sourcing a file with locale
values, the postmaster process doesn't seem to respect it. I'll need
to make this work before I build (I've confirmed that the current way
of handling this, using C, is not acceptable. The locale needs to be
different, and if that causes problems for pgsql, it's a bug in pgsql
which needs fixing - handling other aspects, like ordering, in a bad
way isn't an acceptable workaround.
C equals broken for non-English locales, and isn't an acceptable choice.
That is one argument I'll not be involved in, as I'm so used to the ASCII
sequence that it is second-nature, thus disqualifying me from commenting on
any collation issues.
1) It's not a vaslid choice for English - if you're looking in a
lexicon, you'll find Aspen, bridge, Cambridge, not Aspen,
Cambridge, bridge.
2) It's much worse in other locales... it gets the order of
chaaracters wrong as well.
Here is a test:
create table bar(
ord varchar(40),
foo int,
primary key(ord));
insert into bar values('re',2);
insert into bar values('re',3);
insert into bar values('are',4);
insert into bar values('zsh',5);
insert into bar values('begynne',6);
insert into bar values('ve',7);
select ord,foo from bar order by ord;
Here is a valid result:
are | 4
begynne | 6
zsh | 5
re | 2
ve | 7
re | 3
Here is an invalid result:
are | 4
begynne | 6
zsh | 5
re | 3
re | 2
ve | 7
The last one is what you get with LANG=C - as you can see, the
ordering of the Norwegian characters is wrong. The same would be the
issue for pretty much any non-English characters - their number in the
character table (as used by C) is not the same as their location in
the local alphabet (as used by the local locale).
--
Trond Eivind Glomsrd
Red Hat, Inc.
So there is a reason it is like it is. If you want to change that in the
local setting, you will have to reinitdb in C locale (and
edit /var/lib/pgsql/initdb.i18n accordingly, and be prepared for collation
differences and problems). The initial initdb is done in the system locale,
unless one does not exist, in which case en_US is used (again, so that when
you do store non-English characters you get sane ordering, and so that you
get the mixed-case ordering preferred by many people). The initdb locale
settings are stored in initdb.i18n, and they are re-sourced everytime
postgresql is started to prevent data corruption if postmaster is started
with a different locale from the initdb. Tom, is the data corruption issue
still an issue with 7.4.x, or is this just historical? It has been a long
time since I've looked in this corner of the RPM :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do
Re: [GENERAL] Before ship 7.4.2
On Monday 02 February 2004 07:31 pm, Gaetano Mendola wrote: Is someone taking care about the fact that the pgdb.py shipped with 7.4.1 is the wrong version? What bail me out is the fact that the version pgdb.py shipped with 7.4.1 is a version *pre 7.3*; we add the same bug with the 7.3 and was not solved until the 7.3.2 distribution: 7.4.2 as a tarball does not have pgdb.py in it. The RPMs for 7.4 and 7.4.1 mistakenly added the python client from a separate tarball. I will not be adding this separate tarball this time; a separate python client RPM will have to be built. The RPM's shouldn't editorialize, Tom Lane once said, and including clients in the upstream RPMs that I distribute which are not in the main tarball is editorializing (not to mention the fact that the tarball thus inserted was of the wrong version, for which I apologize). I accepted the contribution of this subpackage from Kaj last time; it will be gone for 7.4.2. Ask the python client maintainers for RPMs of their work. It's a separate project on gborg.postgresql.org now, so a separate RPM for postgresql-python will need to be built by someone in the python client gborg project, or the other python client projects. I know that makes distributors' lives harder (sorry Tom), but it really is necessary. Summary: clients that are removed from the main tarball (such as the Pg module and the python client) will in the future be consistently removed from the RPMs of the main tarball. I once again apologize for not doing that for 7.4 and 7.4.1. For 7.5 this will be JDBC, right? (The JDBC RPM is pretty broken anyway, and downloading the proper jar from jdbc.postgresql.org and making a separate postgresql-jdbc RPM that is not a subpackage won't be hard). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Before ship 7.4.2
On Monday 02 February 2004 10:54 pm, Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: Is someone taking care about the fact that the pgdb.py shipped with 7.4.1 is the wrong version? There is no pgdb.py in the core PG 7.4.* releases. I suppose you are talking about a packaging error in the RPM distribution. Lamar Owen would be the man to talk to about that ... Lamar, any thoughts about this? Well, my first instinct is to throw out the python client RPM entirely. Then package the python client in a separate RPM. My original plan was not to ship a python subpackage at all, but then I had a spec file change contributed that kept the python client in. So I went that direction; principle of least surprise and all. But I am not at all attached to keeping it; likewise, the JDBC stuff could easily be moved to a completely separate RPM instead of a subpackage. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] RPM RH9.0 conflict with unixODBC
On Tuesday 25 November 2003 07:56 pm, Sander Steffann wrote: It turns out that preventing RH9 from building the debuginfo package also prevented it from stripping the binaries. Ah, ok. This was what caused the big difference in filesize. I have rebuilt the RPMs for RH9 and put them on http://opensource.nederland.net/. I had to make a small modification to the specfile (again) because it seems that macro's work differently for each RPM / RedHat version. There have been no other changes to the sources or specfile, so the end-result is the same. Ooo... yet more macro differences. Saturday I'll need to put some time into understanding how to make a singular set... Sorry for the inconvenience I caused by disabling the debuginfo package! Sander. Not a big problem. I'll pull down the new packages tomorrow afternoon; I was going to be off, but will have to come in for a couple of hours. So I'll transfer them across then. Many thanks! -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] RPM RH9.0 conflict with unixODBC
On Tuesday 25 November 2003 07:22 pm, Gaetano Mendola wrote: Sander Steffann wrote: Sorry for the inconvenience I caused by disabling the debuginfo package! Sander. Is this also related to the fact that gdb on libraries of RH9.0 don't complain about the debugging info ? I would think so. But with Sander confirming this by file sizes, we know pretty much for certain. Debugging info really jacks up the file size. It didn't use to be quite that big of a difference, back when I built the beta packages (of which we didn't have any this cycle) with debug info turned on, and unstripped. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] updated linux startup script?
On Saturday 22 November 2003 06:36 pm, CSN wrote: I did initdb -D /var/lib/pgsql/data. I downloaded the attached script from this message - http://archives.postgresql.org/pgsql-general/2003-11/msg01258.php - and will give that a try. (I was getting the same old version errors as well.) I have installed, started, and restarted successfully with the 0.2PGDG set on Fedora. It isn't breaking for me as yet. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] SRPM (PGDG) will not build
On Monday 24 November 2003 12:49 pm, Roderick A. Anderson wrote: Hopefully not fuel to the RPM discussion but I've downloaded the PGDG SRPM this AM made some changes to what packages/portions would build and am now getting the following error. gcc: cannot specify -o with -c or -S and multiple compilations Can you send me a complete stderr and stdout log of the build? (nohup usually works the best to do this, as it catches everything). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Problem with 7.4 RPMS for Fedora Core 1
On Friday 21 November 2003 09:15 pm, milimeter wrote: errors: - An old version of the database format was found.\nYou need to upgrade the data format before using PostgreSQL.\nSee /usr/share/doc/postgresql-7.4/README.rpm-dist for more information. -- Argh. Typo. Replace /etc/rc.d/init.d/postgresql with the attached script. Rename it from postgresql.init to postgresql and put in /etc/rc.d/init.d My apologies. I'll rebuild shortly. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu postgresql.init Description: application/shellscript ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Problem with 7.4 RPMS for Fedora Core 1
On Friday 21 November 2003 09:33 pm, Lamar Owen wrote: On Friday 21 November 2003 09:15 pm, milimeter wrote: errors: - An old version of the database format was found.\nYou need to upgrade the data format before using PostgreSQL.\nSee /usr/share/doc/postgresql-7.4/README.rpm-dist for more information. -- Argh. Typo. Replace /etc/rc.d/init.d/postgresql with the attached script. Rename it from postgresql.init to postgresql and put in /etc/rc.d/init.d My apologies. I'll rebuild shortly. Rebuilding now. While I was at it, I put in conditionals for the 7x and 89 builds. I'll rebuild my 8.0 and Aurora 1.0 builds shortly too; for now I'm blowing them away on the server. Give me a little bit; rebuilding the rh8 one will take 30 minutes or more, and that's after the fedora one has built. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Problem with 7.4 RPMS for Fedora Core 1
On Friday 21 November 2003 09:33 pm, Lamar Owen wrote: On Friday 21 November 2003 09:15 pm, milimeter wrote: errors: - An old version of the database format was found.\nYou need to upgrade the data format before using PostgreSQL.\nSee /usr/share/doc/postgresql-7.4/README.rpm-dist for more information. -- Argh. Typo. Replace /etc/rc.d/init.d/postgresql with the attached script. Rename it from postgresql.init to postgresql and put in /etc/rc.d/init.d My apologies. I'll rebuild shortly. Rebuilding, and have uploaded Aurora 1.0 and Fedora Core 1 RPMS for PostgreSQL 7.4-0.2PGDG. The same source RPM works for both, and works for Red Hat 8.0 (I'm building that one now; my RH8 machine is a creaky old Pentium 150). To rebuild on Red Hat 6.2, executing this should work (but I don't have a 6.2 machine on which to try it) rpm --define 'build6x 1' --define 'plperl 0' --rebuild postgresql-7.4-0.2PGDG.src.rpm To rebuild on Red Hat 7.3: rpmbuild --define 'build7x' --define 'plperl 0' --rebuild To rebuild on Red Hat 8.0 and 9: rpmbuild --define 'build89' --rebuild To rebuild on Fedora Core rpmbuild --rebuild ... I fixed the initscript this time, I think, and made it more portable on the build. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] First generic/redhatish RPM's uploaded to ftp.postgresql.org.
I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am not 100% convinced of the need to do so, I have restructured the directories, and await comment on that. Currently the upload is for Fedora Core 1 only. The source RPM should compile on most recent Red Hat's and close cousins. See ftp://ftp.postgresql.org/pub/binary/v7.4/fedora for the SRPMS and fedora-core-1 directory. As I build the set on other distributions, or as others do so, I will create the appropriate directories and will link the SRPMS dir in each of those to the fedora/SRPMS dir, since that is the master source RPM. Please read README.rpm-dist, found in the postgresql-7.4-0.1PGDG.i386.rpm file, or unpacked in pub/binary/v7.4/fedora, for more details. This set is similar to previous sets in many respects. This is not what I wanted; I wanted to restructure the whole shooting match in concert with Oliver's Debian package restructure. The fewer differences the better, and many parts of Oliver's proposal I plan on implementing in the RPMs verbatim. However, when Oliver released the 7.4 deb without those changes, and due to the SuSE RPM's release, I decided to go ahead with it. Kaj's posting of the patches against the 7.3.4 specfile was a tremendous help in this regard, many thanks Kaj! There were problems, but it was an excellent starting point. There are a few outstanding patches and bugs I need to fix; thus, this RPMset has an 0.1PGDG release tag. I have been somewhat ill this week; maybe by next week I can close some bugs and get us to 1PGDG. Even though the python client is no longer included in the main tarball, thanks to Kaj we have not lost the python subpackage. I expect RH 7.3, RH9, and RH 6.2 packages shortly from Sander, once he reads this mail and gets the time to build them, as he has already asked to help do this. I have RH 8.0 at my disposal, and will build those. I will also be building Aurora 1.0 packages. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] First generic/redhatish RPM's uploaded to ftp.postgresql.org.
On Friday 21 November 2003 01:13 pm, Lamar Owen wrote: I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am not 100% convinced of the need to do so, I have restructured the directories, and await comment on that. I expect RH 7.3, RH9, and RH 6.2 packages shortly from Sander, once he reads this mail and gets the time to build them, as he has already asked to help do this. I have RH 8.0 at my disposal, and will build those. I will also be building Aurora 1.0 packages. Aurora 1.0 and Red Hat 8.0 source and binaries are uploaded. The source RPM has changed a little for each of these, which is noted in the release tag; I have some work to do in the specfile portability, which I will do soon. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] SuSE RPMs available for PostgreSQL 7.4
On Monday 17 November 2003 05:18 pm, Peter Eisentraut wrote: SuSE RPMs for PostgreSQL 7.4 are available at ftp://ftp.postgresql.org/pub/binary/v7.4/suse Hey, Peter, for one who consistently complains about lack of consistency in naming, you completely diregarded the precedent that has previously been set for naming RPM releases (regardless of the source). And then you neglected to put group write permissions on the directory so that other binaries could be uploaded. So now I wouldn't be able to upload RPMs in the customary place. Many thanks. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] SuSE RPMs available for PostgreSQL 7.4
On Wednesday 19 November 2003 02:11 pm, Peter Eisentraut wrote: Official is in the eye of the beholder. If it's on a SuSE CD, then it's official. Everything else is just a series of coincidences. You call yours official, so the SuSE spec file refers to them as such. But in fact, distributors build packages for their distributions and their customers, so making them similar to other spec files is just a secondary effect. So Red Hat's use of the same is just a 'coincidence'. Ok. My effort has been expended not in directly building for every distribution, but for providing a starting point that the distributions can use and modify to their heart's content. By keeping the PGDG set in that role, the various distributions have a common starting point, so at least postgresql works pretty much the same way across distributions. True, but you're under the misimpression that distributors always use your set and then add on their things. But development also flows the other way. So at any one point, one set is never a subset of the other. So there is no hierarchy. No, I'm not under any such misimpression. And the set is 'our' set, not just mine, since the group has thus far allowed the use of the postgresql.org server for distribution. I do not see the RPMs as just being 'mine' -- they are the community's. By having the PostgreSQL Global Development Group's name, download site, and support behind this set means that they are consisdered 'upstream' and the current feel, at least in the Red Hat niche, is to use upstream whenever possible, and to refer bugs, patches, etc back upstream whenever practical. In this particular case, Red Hat employs upstream developers (which is a common thing for Red Hat to do, as they employ many upstream developers in many projects). They do not empoy me; I volunteer my time. But, as I said in another post, if the community is of the consensus that having the upstream RPM set is not a good thing, then I have no problem letting the distributors do their own thing. I just want to make things easier for the users. As to development flowing multiple directions, it's called cooperation. Thus far, most distributors have chosen to use things from our set, and I have chosen to use things that were useful from their sets. Would the same things happen at the same level if our set did not exist? This started in 1999 during the release cycle for Red Hat 6.1, when they chose to use the exact same set I was working on at the time. The exact set I had built was distributed on the Red Hat CD for 6.1. Was it built on others work? Sure it was. Did it use good ideas from other people? I am not a NIHilist, so it certainly did. Was it 'official' in any way? Once I was allowed by PGDG to upload it to the ftp.postgresql.org site, it became, in the view of the PostgreSQL group, 'official' for the group. Have I always done the best job? Not necessarily. Have the distributors' RPMs differed from ours? Yes, their needs and our needs differ. Have they synchronized to our set periodically? Yes, they have. Do they call our set the 'official' set? Yes, they do. Why do you have a problem with this? The directory structure is a mirror of the SuSE FTP site. On ftp.postgresql.org? I'm only talking about ftp.postgresql.org. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] RHEL
On Tuesday 11 November 2003 11:57 pm, Tom Lane wrote: Adam Haberlach [EMAIL PROTECTED] writes: I was, a few minutes ago, stunned to discover that as far as I can tell, the postgres server is not part of Red Hat Server ES Feel free to let Red Hat know that you're unhappy about this. (Not totally unbiased here ... I'm getting *very* tired about RH's internal indecision about their extent of commitment to Postgres. I think frequent whacks-upside-the-head from paying customers may be the only way to get upper management to sit up and take notice.) The RHEL3 beta (taroon) had rh-postgresql-server built and included. Does RHEL3 not include this package? -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Redhat RPMs
On Friday 10 October 2003 08:52 pm, Christopher Browne wrote: Oops! [EMAIL PROTECTED] (Nigel J. Andrews) was seen spray-painting on a wall: I've not looked at many RPMs but I must say that the few I have have never been relocatable. Can the postgresql RPMs not be made relocatable? Unfortunately, relocation would have to include the init scripts, and that would be pretty hairy. The notion of relocatable RPMs came up early in its design, but the only case where that will be particularly usable is if the components are mostly binaries that only make relative path references. That situation is unusual, to say the least. I've been watching this discussion with interest (well, I _am_ the RPM maintainer, after all) and have to say that it has been thought of before. It wasn't at that time implemented due to political factors (read: the then Red Hat maintainer (@redhat.com) refused to include such support even if I had built it). But I did go through the design phase. If everyone can be patient, I'll try to go back into my archives and dig out the design doc I put together way back then. In the meantime, I'd like to hear people's ideas. As alternatives (debian-style) are fully supported in later Red Hat (and the new Fedora Core) releases, a scheme that uses alternatives would be ok. Be sure to post to the pgsql-ports list instead of pgsql-general, though. If the list server will accept it, reply-to has been set to pgsql-ports. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL Beta4 Tag'd and Bundle'd ...
On Monday 06 October 2003 10:08 am, Marc G. Fournier wrote: On Fri, 3 Oct 2003, Relaxin wrote: Unless you are one the core developers of Postgresql it's pretty hard to keep up with what is really going on with this product. no it isn't, just read -hackers ... That is the only way to keep up with what's going on. But you must be willing to take the e-mail volume that that entails. Or use the archive web interface. But -hackers is the place, and has been since the beginning. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] State of Beta 2
On Saturday 27 September 2003 09:45 pm, Joshua D. Drake wrote: $$$ -- I wasn't looking to purchase a programmer. :-) Well sometimes it takes money to get things done. Personally I don't see a big need for pg_upgrade but there was enough people making noise about it that it made sense to make the proposal. Several people did come back and offer to cough up a little bit but not enough to get the project done. I could always forward you my fan mail (context for the following message is that I was extolling the group of people that help me build the various RPM sets as an example of how backports of Fedora Core packages could be done to 'Fedora Legacy' stuff (many thanks to those who help me, BTW.)): === Re: I volunteer From: Chuck Wolber [EMAIL PROTECTED] To: [EMAIL PROTECTED] I as PostgreSQL RPM maintainer for the PostgreSQL Global Development Group do something similar to this using a loose group of volunteers. TROLL Ahhh, so you're the one. Perhaps you could write a postgreSQL RPM with upgrade functionality that actually works? /TROLL -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration| http://www.quantumlinux.com * Support| [EMAIL PROTECTED] = You know, I don't mind owning up to my own bugs. But this bug ain't mine. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] State of Beta 2
Marc G. Fournier wrote: And that has nothing to do with user need as a whole, since the care level I mentioned is predicated by the developer interest level. While I know, Marc, how the whole project got started (I have read the first posts), and I appreciate that you, Bruce, Thomas, and Vadim started the original core team because you were and are users of PostgreSQL, I sincerely believe that in this instance you are out of touch with this need of many of today's userbase. Huh? I have no disagreement that upgrading is a key feature that we are lacking ... but, if there are any *on disk* changes between releases, how do you propose 'in place upgrades'? RTA. It's been hashed, rehashed, and hashed again. I've asked twice if eRserver can replicate a 7.3 database onto a 7.4 server (or a 7.2 onto a 7.3); that question has yet to be answered. If it can do this, then I would be a much happier camper. I would be happy for a migration tool that could read the old format _without_a_running_old_backend_ and convert it to the new format _without_a_running_backend_. That's always been my beef, that the new backend is powerless to recover the old data. OS upgrades where PostgreSQL is part of the OS, FreeBSD ports upgrades (according to a user report on the lists a few months back), and RPM upgrades are absolutely horrid at this point. *You* might can stand it; some cannot. Granted, if its just changes to the system catalogs and such, pg_upgrade should be able to be taught to handle it .. I haven't seen anyone step up to do so, and for someone spending so much time pushing for an upgrade path, I haven't seen you pony up the time I believe I pony up quite a bit of time already, Marc. Not as much as some, by any means, but I am not making one red cent doing what I do for the project. And one time I was supposed to have gotten paid for a related project, I didn't. I did get paid by Great Bridge for RPM work as a one-shot deal, though. The time I've already spent on this is too much. I've probably put several hundred hours of my time into this issue in one form or another; what I don't have time to do is climb the steep slope Tom mentioned earlier. I actually need to feed my family, and my employer has more for me to do than something that should have already been done. Just curious here ... but, with all the time you've spent pushing for an easy upgrade path, have you looked at the other RDBMSs and how they deal with upgrades? I think its going to be a sort of apples-to-oranges thing, since I imagine that most of the 'big ones' don't change their disk formats anymore ... I don't use the others; thus I don't care how they do it; only how we do it. But even MySQL has a better system than we -- they allow you to migrate table by table, gaining the new features of the new format when you migrate. Tom and I pretty much reached consensus that the reason we have a problem with this is the integration of features in the system catalogs, and the lack of separation between 'system' information in the catalogs and 'feature' or 'user' information in the catalogs. It's all in the archives that nobdy seems willing to read over again. Why do we even have archives if they're not going to be used? If bugfixes were consistently backported, and support was provided for older versions running on newer OS's, then this wouldn't be as much of a problem. But we orphan our code afte one version cycle; 7.0.x is completely unsupported, for instance, while even 7.2.x is virtually unsupported. My hat's off to Red Hat for backporting the buffer overflow fixes to all their supported versions; we certainly wouldn't have don it. And 7.3.x will be unsupported once we get past 7.4 release, right? So in order to get critical bug fixes, users must upgrade to a later codebase, and go through the pain of upgrading their data. K, looking back through that it almost sounds like a ramble ... hopefully you understand what I'm asking ... *I* should complain about a ramble? :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute Formerly of WGCR Internet Radio, and the PostgreSQL RPM maintainer since 1999. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Commercial postgresql
On Monday 01 September 2003 22:08, Vivek Khera wrote: I use it in 24/7/365 system which is heavily written to and read from. The drawbacks I have are: Nitpik: that should be 24/7/52, since there aren't 365 weeks in a year. 1) upgrade to major versions require dump/restore which is a significant amount of downtime for a large DB. I have harped on this at length. Maybe one day we'll get real upgrading. Search the archives for the discussions; there are many, and they are long threads. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] 7.3.4 RPM
On Tuesday 19 August 2003 17:46, Sander Steffann wrote: I will build them for RedHat 6.2 and 7.3 this afternoon. You can find them in a few hours at http://opensource.nederland.net/, and maybe Lamar can put them on ftp.postgresql.org. Ah, there you are. Good. I'll upload them tomorrow when I'm back on my T1. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] libpq.so.2 and postgresql-libs-7.3.3 RPM
On Saturday 28 June 2003 23:31, Robert L Mathews wrote: The problem was that the postgresql-libs-7.3.3-1 RPM package advertises itself as providing libpq.so.2, when in fact it does not do so: it provides only libpq.so.3. You're right; they're different. Recompile the client; 'rpmbuild --rebuild' is they way to go. Anyway: unless I'm missing something, shouldn't the Provides: libpq.so.2 be removed from the RPM source spec to prevent this problem? Yes. I will do that for the next release. Alternately, if it _is_ safe to symlink to libpq.so.3, shouldn't the RPM do that? No. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] 7.3.3 RPM build
On Thursday 26 June 2003 16:31, Roderick A. Anderson wrote:
I tried to build new RPMs this morning from the 7.3.3-1PGDG src RPM
because I didn't want tcl or python support. I've done this before with
7.2.1 or 7.3.1. I modified the spec file and the build went OK but when I
tried to install the RPMs I got the following error.
{/usr/src/redhat/RPMS/i386}# rpm -Uvh --test *.rpm
error: Failed dependencies:
perl(Pg) is needed by postgresql-contrib-7.3.3-1PGDG
Argh. That's supposed to be fixed; apparently I did something wrong. Install
it with --nodeps for now, while I regroup and determine why it doesn't work
(again). If you want to help troubleshoot, look at the
filter-requires-perl-Pg.sh script (Source16) and see where it needs to be
invoked
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] 7.3.3 RPM build
On Thursday 26 June 2003 18:34, Manuel Sugawara wrote: Lamar Owen [EMAIL PROTECTED] writes: If you want to help troubleshoot, look at the filter-requires-perl-Pg.sh script (Source16) and see where it needs to be invoked But ... contrib *depends* on perl (see contrib/rserv for instance). May be contrib is too generic. What about split it into packages in order to have working dependencies? Using the filter script is just a hack IMHO. While it _is_ just a hack, until a bona fide Pg RPM for 7.3 is built (by someone, possibly me, possibly someone else), either we must --nodeps or diddle with the perl dependencies. However, more granularity for contrib for the next version would be nice. I'll look at it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] postgresql.conf
On Tuesday 25 September 2001 11:34 am, Mihai Gheorghiu wrote: I installed PG from RPMs. postgresql.conf comes with all options commented out. What are the defaults? PG works anyway (Well... I know... -i etc.) Thank you all. All options commented out is the installation default of a from-source install as well as the RPM install. The default values for the various paramters are commented inside the file, IIRC. Use tcpip_socket=true instead of -i I made the conscious decision to ship the default postgresql.conf -- what optimizations should I make? I can't make generalized optimizations -- so I ship the default file. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] USA Disaster
On Tuesday 11 September 2001 12:15 pm, Carlos Felipe Zirbes wrote: Hope none of us in this list has been affected by that terrorist act. Unfortunately, everyone in the US will be directly affected by this. Some are just more directly affected than others. :-( Hopefully no one on this list will be affected by the war that is likely to result from these cowardly acts. :-( -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] USA Disaster
On Tuesday 11 September 2001 01:51 pm, Manuel Cabido wrote: Can you give us a brief of what really happened out there? How many people have died? What is now the prevailing condition of the place? Had there been leads as to the motive of the attacks? See www.cnn.com, www.msnbc.com, www.foxnews.com, or some other news web site (if you can get through). While this is a horrendous thing, it isn't a PostgreSQL thing -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] USA Disaster
On Tuesday 11 September 2001 02:47 pm, Bruce Momjian wrote: Tom Lane is somewhere away from home in the US so he is already affected because he can't return home. He was supposed to return tomorrow, but that is now uncertain. I call his home and left a message. Well, the PostgreSQL project is then directly affected... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] install only pg_dump
On Monday 10 September 2001 10:24 am, Ben-Nes Michael wrote: I need to do dumps for backups from a redhat6.2 mechine. I dont want to install the whole server for just one utility nor could I find a proper rpm. I currently am not building Red Hat 6.2 RPMs. If you can get RH 6.2 binary RPM's, all you would need installed would be the main postgresql RPMand the postgresql-libs RPM. You would not need the postgresql-server RPM installed for to do a pg_dump. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] How to make a REALLY FAST db server?
- Hardware: dual / quad Intel class The ultimate would be an IBM S/390 mainframe running some distribution of Linux S/390. I/O bandwidth on mainframe DASD is incredible, the memory is robust and fast, and the CPU is trememdous. The price is also trememdous. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] speed of communication and pgsql development
On Sunday 26 August 2001 00:56, Gowey, Geoffrey wrote: Why efnet? They're the only people that I know that still require identd. Unfortunately, I would have to reconfigure the firewall here just so I can get on that net. Has anyone else run in to this problem or am I the only one sitting behind a firewall'd system? Anyone with half a security clue is behind a firewall. Our firewall here won't pass ANY IRC for security reasons. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] New RPMS ?
On Tuesday 21 August 2001 15:16, Carlos Felipe Zirbes wrote: You alway seemed to me a very reasonable and smart person, but to suggest that just because Fernando Lozano is in Brazil he may not have even a Pentium is, to say the least, a terrible proof of ignorance and prejudice. Whoa. I intended absolutely NO offense with my posting of that comment. I have missionary friends in Brazil, Bolivia, and Peru (amongst other places), and they constantly talk about the slower machines they have to deal with, thus the comment. My sincere apologies for any offense, as none was intended whatsoever. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] New RPMS ?
On Monday 20 August 2001 18:09, Trond Eivind Glomsrød wrote: I am not talking just about PostgreSQL now. It is not nice to provide support for a number of customers without Unix and Linux culture and having to recompile everything from sources. :-( If you want newer packages, get Red Hat Linux 7.1. For some folks with older machines, 6.2 is as high as it goes. Ever install 7.1 on a 486? This fellow is in Brazil -- and may not have even a Pentium, for all we know. PostgreSQL 7.1.x, for the record, runs (well, it jogs at least) on even an old 486DX4-100 I had RH 6.2 installed on (48MB RAM). (That machine went on the mission field) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] New RPMS ?
On Sunday 19 August 2001 22:10, Fernando Lozano wrote: Are there plans for 7.1.3 RPMS for Red Hat 6.2 and other systems using the older glibc and rpm format? Yes, once I have enough hard drives to have another system image installed. Due to several other issues, I won't be using either a VMware or similar system, nor do I dual-boot multiple distributions. I prefer having about a 3GB drive for just development -- and I currently do not have a Red Hat 6.2 system installed. You certainly ARE welcome to install RPM 3.0.5 or above on your own RH 6.2 box and rebuild the source RPM -- but I cannot at present do that. And, once a Red Hat 7.2, or 8.0, or whatever Red Hat comes out with next materializes, I will likely migrate my servers to it as well. My apologies. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] AutoStart and AutoDown
On Tuesday 17 July 2001 07:36, IMS wrote: How can I setup in Solaris and Red Hat Linux to start up postgresql automatically? For RedHat Linux, if installed from the RPM's, simply type (as root) /sbin/chkconfig --level 345 postgresql on (assuming you want a postmaster in runlevels 3, 4, and 5). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] PostgreSQL 7.1.2-5PGDG RPMset released for Red Hat 7.1.
Updated RPMs are released for RedHat 7.1. As I no longer have a Red Hat 6.2 or 7.0 machine to rebuild on, this is the only distribution for which I am packaging binaries. The source RPM should build on RH 6.2 just fine, though. This is a minor bugfix release related to RPM packaging bugs _only_. If you are currently using the 4PGDG RPMset, you should be fine, and you don't necessarily need to update. One note: you need the 'mx' Python tools package installed to be able to use the Python client. RPM's for the mx package are available in Red Hat's 'RawHide' distribution -- and that RPM installs just fine on Red Hat 7.1. For your convenience, the mx RPM from the current public RawHide is included in the the redhat-7.1 directory with the 5PGDG RPMs, as that package is not a standard part of RHL 7.1. This dependency has existed since PostgreSQL 7.1 beta -- I just hadn't found it. Many thanks to the team at Red Hat for finding this. The older 7.1.2-4PGDG RPMsets for RH 6.2 and RH 7.0 will remain on the server until I can get 6.2 and 7.0 build systems set up. Files will soon be located in /pub/binary/v7.1.2/RPMS/ on your favorite ftp.postgresql.org mirror shortly. The new README.rpm-dist is available fromthe website. Bugs fixed since 7.1.2-4PGDG: Dependency on mx package. Paths in the prebuilt contrib tree broken. Newer intarray. S/390 patches from RedHat. (Can contribute those to the core) Minor typo update to README.rpm-dist Dependency correction for -devel subpackage. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] 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' dealI can't reproduce it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] Postgresql Python 2
On Friday 13 July 2001 12:20, Peter Eisentraut wrote: Keith F Irwin writes: But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather, installs the new version along side. In other words: /usr/lib/python1.5 /usr/lib/python2 This is a bug in the RPM packages, which our maintainer has evidently neglected to fix. :-/ Reread the spec file. The version of python that answers to the command 'python' will indeed be handled correctly while rebuilding the source RPM. This was fixed a while back. Although I could improve the finding of the path to python instead of hardcoding that. However, note that the _default_shipped_Red_Hat-7.1_ doesn't have python 2.x installed by default -- the python2 packages on Powertools does that. I build binaries for the default _Red_Hat_-7.1_ only. Incidentally, Mandrake 8.0 ships with Python 2.x -- and the source RPM rebuilds fine there (thanks to Justin Clift). The SOURCE RPM can handle any single python version that's installed. Yes, _single_ -- there are way too many customizations that are possible to make it worthwhile to support multiple versions installed . So, to answer Keith's question -- if you want Python 2 modules, you will either need to do what Trond suggested (editing %pyver and hardcoding its definition to '2.0' (or 2.1)), or making sure the command 'python' points to python2. Or edit the pyver definition line to use python2 by default. Is there a need for a whole separate binary RPM for Python 2 clients? But I will reiterate that the prebuilt binary RPMs are built for _stock_ RedHat (and hopefully the systems used to build the non-RedHat binaries are stock, as well). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] Postgresql Python 2
On Friday 13 July 2001 14:47, Peter Eisentraut wrote: Lamar Owen writes: But I will reiterate that the prebuilt binary RPMs are built for _stock_ RedHat (and hopefully the systems used to build the non-RedHat binaries are stock, as well). Maybe the directory naming on the ftp site should indicate this. For instance, I see v7.1-Mandrake, that's clear. But what about the rest (could be the question of a user)? Currently the tree is: /pub/binary/v7.1.2/RPMS/SRPMS /pub/binary/v7.1.2/RPMS/redhat-7.0 /pub/binary/v7.1.2/RPMS/redhat-6.2 /pub/binary/v7.1.2/RPMS/mandrake-8.0 /pub/binary/v7.1.2/RPMS/redhat-7.1 /pub/binary/v7.1.2/RPMS/mandrake-7.2 /pub/binary/v7.1.2/RPMS/mandrake-7.1 Is there improvement yet to be made? Is my structure 'upside-down' (actually, this is the structure Marc started me on.and I have continued)? -- Lamar Owen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Re: [HACKERS] 2 gig file size limit
On Friday 06 July 2001 18:51, Naomi Walker wrote: If PostgreSQL is run on a system that has a file size limit (2 gig?), where might cause us to hit the limit? Since PostgreSQL automatically segments its internal data files to get around such limits, the only place you will hit this limit will be when making backups using pg_dump or pg_dumpall. You may need to pipe the output of those commands into a file splitting utility, and then you'll have to pipe through a reassembly utility to restore. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] defunct postmasters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 11 May 2001 10:26, Philip Crotwell wrote: PS I don't know why this happened, but the only theory I have is that I am running with -i to allow jdbc connections and I had port scanned the machine with nmap shortly before noticing that I could no longer connect. Maybe just coincidence as I don't know if I could connect before portscanning or not, but I have seen other daemons crash after being port scanned. Can somebody say 'denial-of-service?' I knew you could. I'm going to test this one here and see what happens. A port scan should not do this to postmaster. - -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6/AVG5kGGI8vV9eERAjXuAKCA/MY5pmzBY+8SvfXz8Um/RbXWJgCeKCCq rwYqYHFrt4Ir+lcGm7e0Iwk= =iTA5 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] 7.1-1 installation from RPM
Mihai Gheorghiu wrote: /etc/rc.d/init.d/postgresql restart Shutsdown OK, then Checking postgresql installation [OK] Starting postgresql service [FAILED] _I_ need to make some changes. For the time being, don't use restart. This will be fixed for 7.1.1, which I hope to have built by this time tomorrow. /etc/rc.d/init.d/postgresql start by now should succeed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] More src install probs...
David Pieper wrote: I'm trying to build 7.1 from source on a RedHat box. Here's what I keep ending up with: From the gcc version it appears you are on a RedHat 6.x box. It seems like I'm missing something, but what? kernel-headers? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] installing DBD::Pg without installing postgres
Fran Fabrizio wrote: Hello, It seems that there should be a way to install the DBD Pg module without having to install postgres on the local machine. I tried installing just the libs rpm, but that didn't seem to do the trick. I've done some What's the dependencies for the DBD::Pg RPM? Satisfy those dependencies, and properly set up for client-server communications with a postgresql server, and it _should_ just _work_. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] locale glibc 2.2.2
Pimenov Yuri wrote: Greeting! it seems like locale support with glibc 2.2.2 is completely broken... i got huge differences then performing tests in src/test/locale/koi8-r i am running PG7.1 from cvs. PS. locale itself isn't broken for sure Locale collation and other issues were substantially changed for glibc 2.2.2. It is a glibc 2.2.2 issue, not a PostgreSQL one -- as the same codein PostgreSQLO (strcoll) is being used. We will see how things pan out with locale on glibc 2.2.2, as, like I said, there are big changes, apparently. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] 7.1 RPM has old JDBC driver - SQL statement too long
Adam Rossi wrote: I just wanted to pass this along to everyone checking out the new 7.1 release. The jdbc jars that are included with the current RPM's are from the 7.0.3 release. So if you try to take advantage of the new unlimited size text As soon as I can get either pre-built 7.1 JDBC jars to ship as part of the RPM, or get time to install the pieces necessary to build JDBC on RH6.2, RH7.0, and RH7.1. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] locale glibc 2.2.2
Trond Eivind Glomsrd wrote: it seems like locale support with glibc 2.2.2 is completely broken... What exactly is claimed to be broken? If this is the case sensitivity issue, that would count as a postgresql bug. Whatever the sentence above your question means. We'll have to wait on the reporter to elaborate what was meant by '..the locale supportbroken...'. Which case-sensitivity issue? The one about table and column names? Or a different one? (sitting confused in Pisgah Forest) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] locale glibc 2.2.2
Trond Eivind Glomsrd wrote: Which case-sensitivity issue? The one about table and column names? Or a different one? (sitting confused in Pisgah Forest) I remember there were some issues about someone claiming glibc was broken (with LANG set to anything but C/POSIX, because it will sort this way Oh, ok. That goes as far back as glibc 2.1, and first reared its head with Red Hat 6.1. While I've not tested it, I had heard that glibc 2.2.2 'fixed' this. The initscript now explicitly sets locale to C/POSIX for the initdb and the postmaster startup for the RPM, as the locale setting can cause other problems with indexes and the LIKE optimization (although IthinkTom made it where the backend would do the Right Thing and not optimize in the presence of a non-POSIX locale, but I don't remember the details). Time for me to revisit the issue -- after I finish getting my office and servers moved this week and next. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] 7.1 rpm problem
PryT wrote: hi all! i try to install postgresql-7.1.(rpm) on redhat 6.2, but it failed: error: failed dependencies: libpq.so.2 is needed by postgresql-7.1-1 There is more than one RPM needed for the install. You need, for a 'regular' server install 'postgresql-7.1-1', 'postgresql-libs-7.1-1', and 'postgresql-server-7.1-1'. The reasons for this are explained in the README.rpm-dist file found on the website as well as in the RPM. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] postdrv.exe fails on 7.1
Tulio Oliveira wrote: Please, is any configuration more to make on 7.1, or exist a new postdrv.exe ??? See http://www.greatbridge.org/project/psqlodbcplus/projdisplay.php -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] anti Christian bias?
Jan Wieck wrote: I'm not able to find any applicable disclaimers in my copy of the Bible. A quick look into the Koran didn't show up anything either. FWIW, the 1611 King James text is in the Public Domain, as is the source Hebrew and Greek from which it is translated. That of course means that there is no copyright associated with it; thus no license at all. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] 7.1 SRPM woes (Mandrake 7.2)
Len Morgan wrote: Am I missing something? I am assuming that since Mandrake RPMs were done before, they are not the same as the RedHat RPMs and I will have to rebuild from source. I tried the build from the RPM directory (as stated above) and from the SPECS directory as stated in the "Maximum RPM" book both with the same result. What version of Python does Mandrake 7.2 have? (rpm -qa|grep python). I have actually found the 'everything' installs sometimes aren't actually 'everything' -- makesure the python-devel package is installed. Conversely, build everything but the python package by: rpm --define "python 0" -ba postgresql.spec -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] Shared memory failure?
"Justin S." wrote: Thanks Tom. Yeah, I heard that an older version PostgreSQL was used. So if I just use a different port number, and not try replacing the version that comes with the OS, everything should work fine? How do I start PostgreSQL on a different port (and which would you recommend)? Thanks. As the PostgreSQL that comes with that system is from RPM, that version's executables are in /usr/bin -- if you want the new version's executables to be used, put the path to them _before_ /usr/bin in your PATH -- are you WILL be surprised at the buggy results. If you are not actively using the old PostgreSQL, and have the RPMset files to reinstall, you should be safe in issuing an 'rpm -e' for each postgresql rpm that 'rpm -qa|grep postgresql' returns. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Shared memory failure?
"Justin S." wrote: Thanks Tom. Yeah, I heard that an older version PostgreSQL was used. So if I just use a different port number, and not try replacing the version that comes with the OS, everything should work fine? How do I start PostgreSQL on a different port (and which would you recommend)? Thanks. Oh, and BTW: when you rpm-e postgresql, you have to put all of the rpms on one line, or the circular dependencies that sometimes have been present will bite you. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] anti Christian bias?
On Fri, 13 Apr 2001, Bruce Momjian wrote: Lamar Owen wrote: As a matter of fact, I am an ordained Baptist minister. Don't know about Bruce -- other than I like his catchy .sig... :-) Wow, pretty cool. I am just an underling. :-) Well, we're all underlings. At most I can be an undershepherd (as a 'pastor' is -- 'pastor' comes from the same root as 'pasture' -- one feeds, the other is the place of feeding). Well, other than the marriage thing. You do have to have 'the document' to do that. If anyone asks about my .sig, I witness accordingly. Otherwise, I'm not pushy -- not in this venue, at least. Becoming a Christian was the best thing that ever happened to me, and I want to share that, but I don't want to make people uncomfortable either. Your .sig is ideal for this venue. And your choice of names for your children make it pretty well obvious where your heart lies. :-) And I've been in enough Usenet 'discussions' to know what is and is not appropriate. And I've preached enough to enough congregations to, well, have a feel for when it's over the line. And I do get rather 'energetic' in _that_ venue. And accepting Christ was by far the best thing I've ever done. But, to go back on topic, PostgreSQL isn't a religious vehicle, either way. However, if we're going to call it 'Before Common Era' then our date routines really need to use the BCE abbreviation -- otherwise, call BC 'Before Christ' -- although it becomes more than a little paradoxical when you realize after much study (in particular, the times Cyrenius was governor of Syria that intersect with the time Herod the Great was still alive (he died in 4 BC according to most scholars)) that the historical Jesus was most likely born anywhere from 6 to 4 _BC_, making the abbreviation more than a little eyebrow-raising. (ever heard a computer programmer/engineer preach :-)) God didn't set the calendar date -- a man did, 1600 or so years ago. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 http://www.wgcr.org/about_us/who/lamar.htm ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Cant connect if -B 1024 was set to postmaster
"Poul L. Christiansen" wrote: On Mon, 19 Mar 2001, Vilson farias wrote: I changed my /etc/rc.d/init.d/postgresql. The postmaster line now is : su -l postgres -c "/usr/bin/pg_ctl -o '-B 1024' -D $PGDATA -p /usr/bin/postmaster start /dev/null 21" /dev/null I remember having this problem. You need to pass the '-i' switch. Try: '-B 1024 -i' Add the line '-B 1024' to /var/lib/pgsql/data/pg_options along with the -i that is there already, then restart with '/etc/rc.d/init.d/postgresql restart'. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Cant connect if -B 1024 was set to postmaster
"Poul L. Christiansen" wrote: H, don't you mean /var/lib/pgsql/data/postmaster.opts ? Yes, I do. Monday morning. :-) GUC is much nicer in 7.1..one file. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Caldera Install
gambits wrote: I don't want to tear down old installs as I am also running DB2 7.1... Any advice on what the differences are and how I can correct eDesktop 2.4 to work with PostgreSQL.. Download the source RPM on 2.4 and attempt an rpm --rebuild of it, and let me know what it spits back at you. You do need a complete development system, including the python developmet libraries, and at least version 3.0.5 of RPM. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Re: Order question
Mitch Vincent wrote: A further extension of this.. What might I be able to additionally order by so that the most recently updated rows get ordered above everything else (within the order by ordernum).. Using the same example : ordernum | fieldname | oid --+---+- 1 | J.jobtitle| 1197126 1 | J.inv_id | 1197125 2 | J.updatedon | 1197127 3 | J.empinitials | 1197128 I just set the row with j.inv_id to 1, I'd like it to be ordered above the row with j.jobtitle in it -- is that possible? Add a column with a timestamp. Then, in the update/insert, make the timestamp equal the current time. Then ORDER BY ordernum, timestamp. Or better, modify the other ordernums, as you have an ambiguous situation with two ordernums being equal. Writing that in a single UPDATE would be left as an exercise for the reader :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.1 installation problem
Peter Eisentraut wrote: Alexander Jerusalem writes: I'm running into problems while trying to install 7.1 beta 4 (on RedHat Linux 7 with bug fixes applied) I've downloaded the rpms but when I do an rpm -iv postgres-7.1beta4-1.i386.rpm it complains about an unresolved dependency on libreadline.so.3. I have a libreadline.so.4. Is that ok? It should be. The RPMs are broken in that respect. No, they're not broken -- unless being built on RedHat 6.2 qualifies as broken. RedHat 7 has many differences from RedHat 6.2. The best thing to do (until RH 7 RPM's are built -- final release will definitely have RH 7 binaries) is to rebuild from the source RPM on all BUT RedHat 6.2. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] .mips.rpm
"[EMAIL PROTECTED]" wrote: Where can I find postgresql-7.0.x.mips.rpm for my Qube 2?? I try to find them on the FTPs but I have seen anything We have no MIPS RPM's available on our FTP site. More specific information on OS, libc version, kernel, etc would be required anyway. This is because I do not have access to a Qube to build binary RPM's on. If you are able to rebuild from the source RPM, you can download that and try to rebuild it. You will need a complete development environment, including X, installed in order to rebuild from the source RPM. The cobaltqube.org site lists a couple of archives, but neither have PostgreSQL 7 RPM's. The latest Qube RPM for PostgreSQL that I have found is for 6.5.3. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] tuples too big
[EMAIL PROTECTED] wrote: This works well for things like notes and memo's but probably not so good for huge amounts of data. Its flexible and there's no hardcoded limit to the length of data. Sounds something like TOAST, part of PostgreSQL 7.1, to be released soon. TOAST, however, is in the backend itself and is fully automatic. Hardcoded row limits on the amount of data per row (there is still a limit on the number of _columns_ in a row, but not on the size of each column) are gone in 7.1. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] RE: Why is there so much MySQL bashing???
Tony Grant wrote: That can't be good for PostgreSQL, can it? Neither can not being able to do rpm -Uvh and have it work first time... H... When was the last time you tried? Thanks to the 'Do No Harm' principle, it would be foolhardy to do what has to be done to upgrade between major versions in a fully automatic fashion. So the semiautomatic way it is now done is the current best compromise. Of course, the ideal would be for a new version of PostgreSQL to be able to at least read and convert existing tables on the fly (as in when postmaster is started, or when a backend is first brought up on the table in question, or even a standalone migration utility that doesn't require an old version of the backend to read the old version files), but I wouldn't hold your breath. Yes, the existing scheme is a little baroque -- but it's better than it used to be. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] postgresql.conf ignored
hafiz wrote: I use Postgresql 7.0.3-2 in red-hat 6.2 I change several postmaster options through postgresql.conf (in /usr/local/pgsql/data) . But it seems that the postmaster still run using default values and ignored postgresql.conf. I've check the file permission and it should be ok. postgresql.conf is new for 7.1. The proper 7.0.3 file is pg_options, and postmaster.options.sample (IIRC). Might be just postmaster.opts.sample. I don't have a 7.0.3 machine accessible right now to tell -- my production server (for various reasons) is back on a previous version, and my development server has 7.1beta3 installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] RE: Why is there so much MySQL bashing???
Philip Hallstrom wrote: You're right of course, I should have left that out... but my point is still valid. Pointing out the serious limitations in MySQL is not, IMHO, bashing. MySQL currently has serious limitations for many RDBMS uses. Concurrent performance under industry-standard benchmarks in one indicator. I my previous conversations with Monty, anytime I brought up the subject of multiuser benchmarks, he consistently stated that the single-user case was more important, as that's how the current (as of the last time I looked) MySQL 'benchmarks' are structured. Concurrent benchmarking, with a real-world mix of queries (such as AS3AP and TPC-C), is far more useful to those who are using an RDBMS for more than just a web backend. Although, it is a useful average indicator of web backend performance as well. And I have to note that SourceForge switched for performance reasons. Seems there was a great deal of Postgres-bashing from the MySQL side not long ago. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] PostgreSQL v7.1BETA3 Bundled and Available ...
Mike Cannon-Brookes wrote: Will there be RPMs for this beta? (Whoever makes the RPMs ;)) I do, and am working on them. There are a few changes I have to integrate from various sources, as well as stress-testing the build, etc. Look for RPM's Sunday, possibly sooner. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.0.3 rpm testing other problems
[GENERAL only -- got MX errors on two of the addressees] Peter Eisentraut wrote: jpilley writes: I do not have a /usr/share/doc/postgresql-* (or equivalent path) :). I would love to read the README.rpm file, if the 7.0.3 rpm had left me one! On my system this file belongs to package postgresql-7.0.2-17, but the packaging has not changed with 7.0.3. On your system the documentation files might be under /usr/doc instead of /usr/share/doc. Run the following: rpm -ql postgresql |grep README.rpm-dist to get the location. There was a name change in the file due to confusion in KFM and the GNOME file manager -- they were trying to open the README with kpackage or GNoRPM Thanks for the quick answers, Peter. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: SV: [GENERAL] MySQL and PostgreSQL speed compare
Alfred Perlstein wrote: Lamar Owen wrote: But, then again, if the default settings are so bad performance-wise, why _are_ they the default anyway? There should be good reason, of course, but I think maybe the defaults could or should be revisited as to applicability. I can understand someone buying a car to get to and from work and the movies, but you don't enter a racing contest without tuning and knowing a hell of a lot about your vehicle. You obviously have never seen the hillbillies around here try to drag-race their factory stock Corvettes and Camaros. Or the guy who put a 527 Hemi (yes, they do exist) into his otherwise stock Charger and kept wondering why the transmission made funny noises, the driveshaft kept twisting, the differential kept exploding, and the tires kept wearing out. Saw it. There are far more shadetree mechanics who couldn't tune a tuning fork try their hand at building a racecar than mechanics who actually know the balance of power in the drivetrain -- big engine = big transmission = big driveshaft = big punkin with lockers or limited slip units = wide wheels with large bead surfaces = heavy wide tires with a Z speed rating. There are many less that understand that solid iron rod does not make a good heavy duty driveshaft. Or that understands that a car that performs well on the dragstrip may not do so well on the closed track length race. Likewise with self-proclaimed computer tuners. I really don't understand why people expect computers to do everything for them, the burden of using tools properly belongs to the user. I of course agree in principle to this statement (and the whole tone of your reply) -- but, my statement doesn't reflect my opinion -- it reflects reality. Facts are stubborn things. Of course the defaults will never be perfect -- nor will all users RTM. But, therein lies the utility of 'defaults' benchmarking -- let's see what the trade offs really are so that we the 'experts' can intelligently recommend things -- as well as intelligently tweak the defaults. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] red hat/mysql fiasco
Alvaro Herrera wrote:
On Thu, 21 Dec 2000, Alessio Bragadini wrote:
Mandrake packages for Postgresql are also flawed, in 7.2 at least. When
you cast some strings as timestamps, you can get weird values ("0:10:00"
- "0:09:60"). It's also a compiler problem.
Fortunately, Postgresql-packaged RPMs for Mandrake don't have this
"feature".
Could be a bad -O setting. The way RPM works in the build process
(which is, IMHO, not very good) means that typically the spec file that
controls the build sets the compilation options to include potentially
faulty combinations with certain programs.
Mandrake is known for aggressive -O settings.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Re: [GENERAL] Large files on linux
Peter Eisentraut wrote: Fernan Aguero writes: I am having trouble with large files on a Linux box (RH 6.2). I know there is a limit of 2 GB on the file size, ...but that doesn't affect table size, database size, or whatever you're thinking of. Nope, PostgreSQL segments nicely for tables. But, unless you do chunking, it _does_ affect dumpfile size. Someone posted awhile back a script that did dumpchunking. Should be in the archives. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Many postmasters...
Jean-Christophe Boggio wrote: Using Linux RH7.0 with correct gcc and glibc, PG7.03, Apache 1.3.14 and PHP4. We have several unresolved questions : * Is it normal that ps aux |grep postgres shows (what we want : processes own by postgres) multiple postgres backends (which seems normal to me) *AND* multiple postmaster (same full cmd line). Sometimes we also have "defunct" postgresses. Yes, this would be normal. Due to the fork nature of the backend, you will see with ps, depending upon traffic, the actual postmaster fork before the backend (postgres) is exec'd. I don't see that here due to my use of a pooling webserver, but non-pooled situations will have backends bouncing up and down constantly. The defunct postgres processes are the ones that are going away, but haven't yet been removed from the process table, IIRC. * we start postgres with a /etc/rc.d/init.d script that launches pg_ctl -w many options here start When invoked from the shell, this command never returns to the shell by itself, we have to press enter. This behaviour prevents the script for terminating properly. Is there a way around this ? Not tried echo | pg_ctl yet The init.d script has an after the pg_ctl line. If it didn't return, your system would never finish booting, due to the sequential nature of the RedHat 7 SysV init setup. Now, pg_ctl is kept running; it just doesn't block the initscript. * every backend created by an Apache session opens many files (in our case, about 80 including the indexes) and many backends will finally generate an "Too many files open" message. We first increased the /proc/sys/fs/file-max to 8192 but that's a lot ! The apache/php server always uses the same connect parameters for every page but it seems php's pg_pconnect() behaves just like pg_connect. Shouldn't we have apache hold a few backends connected ? Thanks to the non-pooled connection scheme of Apache/PHP, the way the persistent pconnect mechanism works is non-obvious. Each apache _process_ can hold a configured number of connections open -- but that is then multiplied by the number of apache _processes_. So, to run persistent connections in a usable manner on Apache/PHP requires a huge number of backends, requiring an even larger number of open files. File-max at 8192 is probably middle of the road for such a system. Too bad PHP can't use AOLserver's pooled connections -- that would be a big win. PHP can run on AOLserver -- it just doesn't yet use the pooled API. Apache 2.0's multithreaded nature will help this -- unless a mechanism can be devised to share database connections amongst multiple full processes for older Apache's. Multithreading is a big win for clients that generate multiple connections -- it's not a big win for backends that serve multiple connections. IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Strange problem upgrading to 7.0.3x
Rich Shepard wrote: On Thu, 16 Nov 2000, Lamar Owen wrote: The result of 'rpm -qa|grep postgres' would be educational here. [root@salmo rshepard]# rpm -qa | grep postgres postgresql-server-6.5.3-1 postgresql-test-6.5.3-1 postgresql-7.0.3-2 "Aha, I said. The rpm database thinks that postgresql-server, and -test are still installed." Then I tried to erast the server: Ok, do the following steps: rpm -e --nodeps --noscripts -- force postgresql-server postgresql-test postgresql What is happening is that, since the uninstall scripts for server are not completing, the server uninstall is failing -- producing the results you have seen. Once you have verified with rpm -qa|grep postgres that there are no more postgresql RPM's on your system, then you will need to clean out the old 6.5.3 data directory (rm -rf /var/lib/pgsql). Now you should be able to install the new RPMset. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Strange problem upgrading to 7.0.3x
Rich Shepard wrote: Thanks, Lamar. I upgraded the server package, and that appeared to work just fine. Then I installed the others. Is 'initdb' the proper way to restart everything, and creat a new /var/lib/pgsql? It's been a while since I worked with postgres, but I need to really dig into app development now. You can let the packaged initscript do it for you, as long as there is no previous database structure in place under /var/lib/pgsql -- you would want to remove everything below that dir EXCEPT the subdirs data and backups, as well as .bash_profile. Execute as root '/etc/rc.d/init.d/postgresql start' and it will both initdb and start the postmaster for you. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Strange problem upgrading to 7.0.3x
Rich Shepard wrote: So, can someone please explain to me why the 7.0.3-1 package complains that /lib/cpp isn't there when it is? FWIW, I got the same error when I tried using the --force switch with rpm. Something's screwy here. Use --nodeps to override dependencies. It is complaining because RPM apparently has no record of /lib/cpp -- rpm --rebuilddb may be needed. RPM's dependencies are not checked against the filesystem, but against the RPM database. You can verify this by executing 'rpm -qf /lib/cpp' -- see what it says. However, the error should not have occurred in the first place -- I guess a -2 RPMset is in order. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[GENERAL] Updated RPMset available (7.0.3-2)
Due to a dependency problem, which only reared its ugly head if no C preprocessor was installed, I have rebuilt and re-released RPM's for PostgreSQL. If you have not experienced problems with the 7.0.3-1 RPMset, you do not need to download this set. Available at: ftp://ftp.postgresql.org/pub/binary/v7.0.3/RPMS or on your favorite PostgreSQL mirror. PPC RPM's should be available soon, as should Mandrake 7.1 RPM's. Caldera eServer 2.3, RedHat 6.x and 7.0, TurboLinux 6.0.4, and SuSE 6.4 and 7.0 i386 binary RPM's are available, and a cross-distribution capable source RPM is also available. Source RPM's for eServer 2.3 and SuSE are also available, and are packaged in the respective directory. The SuSE RPM's, due to their different source, are not updated to 7.0.3-2, as the dependency problem doesn't exist on them. Again, if you took the time to download the 7.0.3-1 RPMset, and it installed for you just fine, you do not need to download this set. If you downloaded the 7.0.3-1 set, and the only dependency that fails on installation is for '/lib/cpp', then you may safely use rpm's --nodeps install flag to force the installation. In addition to the change for this dependency bug, the 7.0.3-2 RedHat-style RPMset has experimental build support for ia64, as well as better build support for PowerPC, which prevents building with too high an optimization level. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Script Location
Paul M Foster wrote: When I dump a database (creating a script from the pg_dump command), I can't just put it in any old directory and point psql at it. I have to put it in the /var/lib/pgsql subdirs before postgresql will accept it. Is this right? Am I doing something wrong? Is this a bug^H^H^Hfeature? You just have to point the output of pg_dump to any directory owned by the user running pg_dump. Since you mention /var/lib/pgsql, I'm assuming you are using an RPM installation. If my assumption is incorrect, correct me, please. In the default RPM installation, /var/lib/pgsql serves multiple roles: /var/lib/pgsql is ~postgres /var/lib/pgsql/data is PGDATA /var/lib/pgsql/backups is designed as a repository for your dumps. This gives you a 'safe haven' for your dumps that is owned by the user postgres, which is the default database administration user for the RPM installation. If you attempt to pg_dump to a file in a directory not owned by postgres, you will get an error. Likewise, if you have a dumpfile from another system in a directory where the user postgres (or whatever user you are trying to pipe the dump through psql back in) doesn't have read and execute permissions, you will get an error. To correct this problem, set your permissions appropriately in the directory you wish to use. Hope that helps! -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.0.3 RPMs?
Matthew wrote: When are the 7.0.3 RPM's expected to be released? Most of my production servers use the RPM install and I would like to keep it that way, however I would also like to move up to 7.0.3 some time soon. Just wondering... Today. Working on it now. What distribution are you using? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.0.3 RPMs?
Roger Wernersson wrote: Will there be an RPM for Alpha? What distribution? I haven't yet rebuilt the RPMset on an Alpha for 7.0.3 -- if you want to take a shot at it, you can try. It will be interesting to see if the 7.0.2 alpha patches apply smoothly and work correctly for 7.0.3, as Ryan hasn't yet released a 7.0.3 patch. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.0.3 RPMs?
Matthew wrote: I just checked the FTP site, and found the 7.0.3 RPMS. thanks much... I will try them out tonight. Wait until I announce their availability -- a minor dependency problem was just found that I need to fix before anyone uses those RPM's that have been uploaded. Silly little error on my part, really. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] postgres on redhat 7.0
"Robert D. Nelson" wrote: In general I am pretty pissed at RH attitude to system upgrade, if I were working in a Production environment, I would either hire them and not try anything myself, which kinda contradicts the whole Linux philosophy. Can this kind of stuff get put on a Red Hat mailing list, rather than sent here? Thanks! pgsql-ports for PostgreSQL related stuff. I will announce soon some exciting news related to the RPM's, as well as a dedicated 'postgresqlrpms' mailing list, and the RPM spec files, patches, etc, under a public CVS server. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] postgres on redhat 7.0
Adam Lang wrote: But it don't help if you downloaded the OS. ;) If you downloaded the RedHat CD ISO images, OR the ftp dirs, you got the postgresql RPM's, unless you specifically excluded them. And you can certainly get them from RedHat's ftp site, as busy as it is. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] --enable-syslog in rh7 ?
"Sergio A. Kessler" wrote: i was reading in the docs that that for syslog (ie. syslog = 2 in pg_options) to effectively work, you need to build postgres with --enable-syslog PostgreSQL 7.0.2 has no --enable-syslog switch. 7.1 (and, apparently 7.0.3) will have such a configure switch (it exists both in CURRENT and REL7_0_PATCHES in CVS). so the question is: if I put syslog = 2 in pg_options, it will work in a rh7 with postgres out of the box ? Yes, it should. The patch was necessary for 7.0.2, but not for later than that. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] pg_check 0.1.3 is now Available
Bryan White wrote: pg_check is a command line tool I have written to aid is diagnosing and recovering from PostgreSQL table corruptions. See the ReadMe file for more information. Fascinating. Looks like a possible framework for building a standalone dumping utility.for migration -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] postgres on redhat 7.0
Adam Lang wrote: Which leads me to a question. Why do so many people ask the list where the most current RPMS for Redhat are located? Not trying to start trouble, but doesn't it seem obvious to check the Redhat site? Just wierd that so many people ask where to find them... Well, we maintain RPM's ourselves (or should I say, I maintain RPM's myself) -- but due to the lack of a RedHat 7 machine for me to build on (at this time) the best place to get RedHat 7 RPM's is with RedHat 7. I just announced the newest set -- there will be more announcements later this week or early next week as I build binaries on other architectures (I'm even working on building Hercules so I can build/rebuild for S/390 on my Intel box -- Hercules is an ESA/390 emulator -- slow as Christmas, but will run Linux/390 well enough to build/rebuild RPM's. My goal is posting working S/390 binaries on ftp.postgresql.org -- the coolness factor alone is worth the work) and other distributions (such as TurboLinux, Caldera eServer, and SuSE -- although SuSE has a 7.0.2 RPMset of their own that is substantially different from ours, even though it is based on ours). Unless someone want to offer me a shell and build privileges on a Linux/390 VM on their real S/390 :-). In fact, I'm requesting that people running something other than RedHat 6.2 on Intel try to --rebuild the src.rpm I just posted so that I can get binaries for multiple architectures. If you need to patch the spec file or whatever else to get it to run, send the patches my way so we can make it just a simple --rebuild for most folks. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] how good is PostgreSQL
Steve Wolfe wrote: Even after that, you have a long way to go before you will hit 1000 transactions per second from any SQL database. I guess they could always buy a few Sun E1's on the backend, and a large room of rack-mountable PC's for web/CGI serving. Nothing like plopping down ten or twenty million dollars on hardware. : ) Or they could buy a single IBM S/390, run Linux/390 and PostgreSQL on that. Probably would cost less, and be more reliable. And they can always load another Linux/390 VM -- an S/390 can run something like 41,000 virtual machines each running Linux/390 and Apache. However, if you want to see the architecture of a _large_ database-backed website, see the story behind Digital City at www.aolserver.com. While they're using Sybase instead of PostgreSQL, the architecture is the same. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Postgres 7.0.2-2 on Red Hat 7.0?
Steve Wolfe wrote: Then upgrade the RPM's. It isn't hard. OK, here's a situation. One of the programmers at your company runs the disk out of space. You're going to go bonk him on the head, but first, there are more pressing matters. PostgreSQL 6.5 has horked up the tables, and needs to be fixed. 7.0 is released, which has a fix for the problem. Not a good example, but I understand your comparison. Are you going to sit around waiting for RPM's, while your tables are all horked up, and the programming department is breathing down your neck because they can't get work done? Actually, since I'm the RPM maintainer, I'll build a set for the new version (which I would have been tracking since the first beta) the hour it is released. That is if I'm online when the release occurs. But, then again, I'll have already built RPM's for the beta releases. It's this very problem that got me in this business of maintaining the RPM's in the first place over a year ago. Scratch that itch. If you're going to install from source on a RedHat machine, it is simply prudent practice, regardless of the package, to make sure the RPM version is not already installed. I agree. And, the fact of the matter is that there are likely far more PostgreSQL installations from RPM than from source. I fail to see the relevance of that argument. Popularity does not make correctness. If I'm just being extremely dense about that sentence, feel free to let me know. The relevance is that most who use it don't really care where the stuff is. They just want to upgrade. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Bruce Momjian wrote: Trond Eivind Glomsrød wrote: How compatible with 7.0 and 7.1 be from an application standpoint? Will applications linked with libraries from 7.0 be able to talk to the 7.1 database? Any changes in library major versions? The other way? Historically, all applications have been able to talk to newer servers, so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients can talk to 7.1 postmasters. We usually do not go the other way, where 6.5 clients can not talk to 6.4 postmasters. I believe 7.0-7.1 will be able to talk in any 7.0.X/7.1 client and server combination. He's meaning the libpq version for dynamic link loading. Is the libpq.so lib changing versions (like the change from 6.5.x to 7.0.x changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM compatibility for other RPM's linked against libpq.so.2.0, which failed when libpq.so.2.1 came on the scene). I think the answer is no, but I haven't checked the details yet. Not just libpq, though -- libpgtcl.so has also been problematic. Of course, the file format on disk changes (again!), which is a whole 'nother issue for RPM's.. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] pgsql 7.0.2 on RH6.2 regression test failed
Douglas wrote: Since I'am new to linux and pgsql, and I really want to know about what was going on in the pocess, I didn't use rpm. and my linux kernel is 2.2.17. I only use enable-locale and enable_multbyte=EUC_TW as the configuration parameters. Ok. To pass regression, you need to rename /etc/sysconfig/i18n to some other name, reboot, and rerun regression. If you have installed postgresql in /usr/local/pgsql, as is recommended by the source distribution install documentation, then use that set of environment variables. If you have it installed in /opt, then use that set of variables. The gist being that those variables need to point to where the files referenced by them actually reside. After passing regression, you'll need to put /etc/sysconfig/i18n back in place if you want locale support. But expect 'unexpected' collation orders. The collation is unexpected by Unix standards, but is according to ISO standards. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Re: [HACKERS] My new job
Adam Lang wrote: (Actually, under GPL, any modifications of the code have to be free also, correct?, so it can't really be proprietised unless they make an add-on that is private... but then postgres can be run and compiled without it). PostgreSQL is not under the GPL. PostgreSQL has (and always had) a BSD license -- which means there is no license restriction on 'proprietizing' PostgreSQL code. But, as many others have said, the core team seems to have a good hold on reality and their ethics, so it probably won't come to an issue. :) This is the real safeguard. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Redhat 7 and PgSQL
Trond Eivind Glomsrød wrote: "Alfredo" [EMAIL PROTECTED] writes: I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? No. Postgresql is included, and is the one installed when choosing "SQL Server" under the custom category. To get MySQL, you would have to install them manually afterwards, select "everything" or choose to manually select packages. Not to mention that the MySQL packages are the GPL'd 3.23 _alpha_ code. Of course, we may switch the defaults in the future if we think MySQL is a better database in terms of upgradability, reliability, features and performance but there are no such plans right now. And PostgreSQL's reliability, features, and performance are sterling -- and the replication server being developed by PostgreSQL, Inc helps. But, upgradability is, well, almost nonexistant. No, dump/initdb/restore is not a real upgrade; it's a kludge (and doesn't necessarily work). I know one datamodel in particular that is currently having problems with databases restored from a pg_dump. We'll see if the 7.1 pg_dump helps. Currently, MySQL has us beat on the upgradability issue. And I cannot overemphasize how important a smooth upgrade is to a distribution maker like Red Hat. I am looking at the feasibility of the upgrade utility I mentioned a few weeks ago, and am finding it rough going. But, we'll see. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Redhat 7 and PgSQL
Tom Lane wrote: "Efrain Caro" [EMAIL PROTECTED] writes: Forgive my ignorance. What is this no-upgrade policy issue about? It's not a "policy", it's just a problem: you usually can't update to a new major Postgres release without doing dump/initdb/reload. The 'policy' is the lack of assigning developer time to fixing the problem. Smooth upgrades could easily be sold as a major feature. IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] php and pgsql and rpm/compile
Adam Lang wrote: I have php installed from rpm. I'm trying to rpm the package php-pgsql-3.0.15.i386.rpm so that I can tie in to the postgres server. It is coming back with a dependency for libpq.so.2.0 The original packages distributed with RH 6.1 and 6.2 are for PostgreSQL 6.5.3 -- and the other RPM's built from that same distribution depend upon PostgreSQL 6.5.3's libpq -- which is 2.0. I have /usr/local/pgsql/lib in the ld.so.conf file. I'm not sure what else to try, but I really hope the answer of "compile php" isn't the answer. You can install the 7.0.2 RPMset, grab the source RPM for php, rebuild it using (as root) rpm --rebuild php*.src.rpm, and install the freshly built packages with rpm -i from /usr/src/redhat/RPMS/i386. Of course, that rebuild will require a relatively complete development machine... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] php and pgsql and rpm/compile
Tressens Lionel wrote: Le 07.09.00 a 14:23, "Lamar Owen" m'ecrivait : It is coming back with a dependency for libpq.so.2.0 I had this problem. I created a symlink for this file and a told rpm not to check dependies, and it worked. rpm --nodeps -ivh ... And, if you know the ramifications of --nodeps, that is a good solution. But, beware the ramifications of --nodeps. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL]
Lee Johnson wrote: just wondering is postgresq a program that will allow similar things as does microsofts's access..i use access for my current database for company.. cuz i've noticed in the description things like "server"..which i'm not on i'm end user of linux looking for good database for use in linux to switch over from using access.. PostgreSQL comes with a nice front end called pgaccess that will do most if not all of what you need under linux. You will be setting it up client-server -- just having the client and the server on the same machine. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Re: Lock up on 7.0.2 involving CREATE FUNCTION/INDEX..
Philip Hallstrom wrote: Oh... Duh!!! Geesh... for some reason I figured it would call the "built-in" UPPER, but obviously it won't. ha ha ha. *sigh* My next question then is how to get around this? I could just rename my function but it's nice to leave it UPPER since that is what it does. Is there another function that will uppercase? Or is there some way to call the other UPPER function? Or something within plpgsql I don't know Uh, maybe I'm missing something, but, just _why_ do you need a pl/pgsql function named UPPER that does nothing but call the built-in upper()? Is there a type mismatch problem I'm not seeing? Why do you need to do this? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Re: Lock up on 7.0.2 involving CREATE FUNCTION/INDEX..
Philip Hallstrom wrote:
CREATE INDEX test_idx ON test (UPPER(field));
devloki= create index foo on rolo_entry (UPPER(fname));
ERROR: DefineIndex: function 'upper(varchar)' does not exist
devloki= create index foo on rolo_entry (UPPER(varchar(fname)));
ERROR: parser: parse error at or near "varchar"
devloki= create index foo on rolo_entry (UPPER(text(fname)));
ERROR: parser: parse error at or near "("
devloki= create index foo on rolo_entry (UPPER(text fname));
ERROR: parser: parse error at or near "fname"
devloki= create index foo on rolo_entry (UPPER(fname::text));
ERROR: parser: parse error at or near "::"
devloki= create index foo on rolo_entry (UPPER(CAST(fname AS TEXT)));
ERROR: parser: parse error at or near "cast"
So, by creating a function such as UPPER(varchar) instead of the built-in
UPPER(text), I can do what I want.
What's odd, is that I can create the function UPPER(varchar) which then
calls UPPER(text) and use it all I want. However, if I then try to create
an index (like my first example above) it locks up the entire machine.
That is wild. I'd say bring this up in the hackers list -- as upper
should also work with varchar by default.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Re: [GENERAL] libperl.so
Charles Tassell wrote: There is also a way to recompile a .a library into a shared library. Something like: ar x library.a ld -shared -o library.so *.o But a shared lib is _supposed_ to be compiled with position-independent code with -fPIC -- otherwise you are just asking for trouble to simply relink in this way. It may work for you (as it does for me with pl/perl, and for Karl DeBisschop), but it is highly unlikely it will work for everyone, and it is likely to cause performance issues even if it does work. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
