Re: [GENERAL] postgresql 7.1.3
Lamar Owen <[EMAIL PROTECTED]> writes: > On Tuesday 16 October 2001 02:39 pm, samsom, debra wrote: > > I just installed postgresql 7.1.3 on Linux Redhat 7.1. All is well except > > Postgresql will not start on Boot. I have added the -o '-i' to the > > postgresql.conf and done the chkconfig --add postgresql. Is there anything > > else that I am missing? > > My apologies. In my README.rpm-dist I missed a step: > chkconfig --level 345 postgresql on You don't need the levels if you don't want to e.g. have it only start in runlevel 5... chkconfig postgresql on is sufficient for most use. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Encoding passwords
Marko Kreen <[EMAIL PROTECTED]> writes: > Another idea is stop storing hashes altogether You can already avoid passwords by using kerberos authentication. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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?
bpalmer <[EMAIL PROTECTED]> writes: > I'm looking to make a DB server for a project I'm working on (using pgsql) > and am wondering if people have suggestions? > > Thoughts: > > - Hardware: dual / quad Intel class Athlon gives more bang for the buck - the dual Athlons are _really_ nice, and have proven stable as well. > - Disk: SCSI Raid 1+0 I'd probably go for a 3ware RAID instead... IDE disks are so much cheaper nowadays than SCSI, and the premium isn't really justifiable anymore. > - OS: Prolly FreeBSD (FFS is your friend (what with syncs and all) and it > can do multi proc support I'd recommend Linux, which has more mature MP support and scales better, but I'm obviously biased :). It's of course very important to keep what you are familiar with - a good sysadmin makes a world of difference no matter what you're using. > - Ram: Not really sure here. Is there math somewhere for ram needs for > pgsql? I imagine is has something to do with # connections, db size, > etc. "More is better. RAM is cheap. Avoid RAMBUS". -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Justin Clift writes: > > > If anyone else can see things blatantly wrong on that page, email me > > about them and I'll ask Monty (the MySQL guy) to please > > change/remove/fix them. > > > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > > Many of these advantages can easily interpreted as disadvantages. For > example: > > * MySQL has more API to other languages and is supported by more programs > than PostgreSQL. See section D Contributed Programs. > > => MySQL has 6 Perl modules, 5 ODBC drivers, and 4 C++ interfaces. > PostgreSQL concentrates its efforts on making one driver work best for all > users. For interfaces, it's best to have only one, and a good one (like one DBD module for perl, one JDBC interface for Java, one python module implementing the Python DB API (there are several Pg ones available here)). But this didn't just focus on APIs. > * There are far moore books in print on MySQL than on PostgreSQL. > O'Reilly, Sams, Que, and New Riders are all major publishers with books > about MySQL. > > => MySQL is so hard to understand and poorly documented, a plethora of > books had to come out before anyone could use it. That is a ridiculous claim. More documentation is good - like how to apply the different scenarios and by different authors. From "Foo in 24 hours" to "Data mining with bar". > * All MySQL features is also documented in the MySQL on-line manual > because when a feature is implemented, the MySQL developers are required > to document it before it's included in the source. > > => blah... :-) The MySQL documentation is actually rather nice (not saying that the PostgreSQL isn't). > * MySQL has support for tables without transactions for applications that > need all speed they can get. > > => MySQL is not a fully transactional database system. It defaults to this as well, AFAIR. > * MySQL has internal support for text search. See section 6.8 MySQL > Full-text Search. > > => PostgreSQL has a number of different full text search solutions > available, or users can plug in their own. Weren't you the one preaching the wonders of "one way to do it" (API-wise) above? > * You can access many databases from the same connection (depending of > course on your privileges). > > => PostgreSQL does not allow you to access more than one database per > connection. This makes the system much safer and allows for more robust > design. Sometimes, you'd like to anyway ;) The person doing the bugzilla port would even like to have multi-DB operations (and split tables, with parts of the query running on each one). > => PostgreSQL is coded from the start with multi-processing while MySQL > uses threads. Threads have historically led to much more bug-prone > programs and are poorly supported on many operating systems. If one > thread crashes your whole server goes down. > > * MySQL has a much more sophisticated privilege system than PostgreSQL. > > => MySQL has a much more complicated privilege system than > PostgreSQL. There is a difference between what must be done and what can be done. E.g. you can use Emacs quite comofortably as a very powerful editor without knowing much lisp. You can do anything you want if you need to. > * MySQL employs the table handler concept and is the only relational > database we know of built around this concept. > > => MySQL employs a table handler concept, which makes your code much less > SQL compliant and makes MySQL harder to learn. Do you have to use it, or is it something you can choose to take advantage of? > * Tools to repair and optimize MyISAM tables (the most common MySQL table > type). > > => In MySQL you have to repair your tables manually if corruption occurs. > PostgreSQL is coded so that corruption cannot occur. You sound like H.R. That's not a compliment. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] RedHat startup script and environment variables in 7.1.2?
Steve Wampler <[EMAIL PROTECTED]> writes: > It looks as though the init.d script "postgres" supplied with > 7.1.2 no longer propagates environment variables to pg_ctl. Was that > an intentional change? Or is this something no one else sees? It's an unintentional sideeffect of fixing the "I changed the postgres' users shell to tcsh and things don't work like they used to" problem. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Problems with installation v 7.1.2
"Hicnar" <[EMAIL PROTECTED]> writes: > Hello, > > I was trying to install PostgreSQL ver 7.1.2, for RH 6.2, but some packages > depend on ssl.so.0 and crypto.so.0 libraries. > > The question is: what packages contain those libs??? openssl. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] New RPMS ?
Fernando Lozano <[EMAIL PROTECTED]> writes: > Are there plans for 7.1.3 RPMS for Red Hat 6.2 and other systems using > the older glibc and rpm format? FWIW, while a version for RHL 6.2 makes sense because of glibc issues (and other libraries), the supported rpm format for RHL 6.2 is v4. Erratas (you have applied those, right? ;) also come in that format. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] HELP! BUG? pg_dump mucks up grant/revoke
Tom Lane <[EMAIL PROTECTED]> writes: > Lamar Owen <[EMAIL PROTECTED]> writes: > > A pg_dump that can't be restored should be a release forcer, IMHO. > > Let's not panic here. The actual net effect of these bugs will be that > the pg_dump output script fails to restore the permissions and/or > comment associated with a view. Which'd be annoying, but hardly > something to ruin your whole day. The impact will vary from location to location... but given that this is the only way to upgrade the database (as you know, this is one of my pet peeves), it needs to work. > pg_dump issues, but the WAL truncation fix seems to be something that > lots of people need. Are those also in the 7.1-stable branch? -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] readline and rh7.1
On Mon, 30 Jul 2001, Ben-Nes Michael wrote: > The RPM support locale ? The newest ones do. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] readline and rh7.1
"Ben-Nes Michael" <[EMAIL PROTECTED]> writes: > Yes I did with locale + debug It's known to work in the official RPMs. I suggest you take a look at those, and at the output from configure on your own system. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] readline and rh7.1
"Ben-Nes Michael" <[EMAIL PROTECTED]> writes: > The readline support don't work under Red Hat 7.1. Yes, it does. I'm guessing you compiled postgresql yourself? -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
Lamar Owen <[EMAIL PROTECTED]> writes: > On Friday 20 July 2001 11:24, Bruce Momjian wrote: > > Let me add that Red Hat is now distributing a different RPM with their > > Red Hat Database, or at least I think they are. Can someone confirm? > > Trond may be able to. The rpms of the Red Hat database are called rhdb, to avoid confusion. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Postgresql & Python 2
Peter Eisentraut <[EMAIL PROTECTED]> writes: > 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. Exactly what bug are you thinking of? The current build process tries to detect your current version of python and build for that.. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] A small question about Red Hat
(not relevant to postgresql, so I suggest you ask this on e.g. redhat-list: http://www.redhat.com/mailing-lists/ ) "Kapil Tilwani" <[EMAIL PROTECTED]> writes: > Red Hat is Open Source and is freely downloadable, right? But, if I > have acquired a CD from some source, other than Red Hat, can I install > on unlimited Computers? Yes. > Secondly, what if he had purchased the CD, would a copy of it be > illegal? No. > Also, is it easy to learn FreeBSD for someone like me who knows just > VB and not even NT completely. Is FreeBSD graphical also? It has the same underlying programs as Linux has for graphical display (X, Gnome/KDE) - you might have a harder time getting accelerated 3D graphics, other than that, the programs are similar. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: Red Hat to support PostgreSQL
"Steve Wolfe" <[EMAIL PROTECTED]> writes: > > Previous to version 7.1, RHL wasn't very secure by default. This is one > of > > the most common complaints I hear. 7.1 can be made quite secure out of > the > > box without any special config -- just leave the firewall config at the > > default of 'HIGH' -- of course, I've now heard complaints that it is then > > 'too secure' :-). > > Myself, I'd prefer that they'd just leave the insecure services off by > default, rather than using a firewall as a "band-aid". ; ) ALmost all services are off as well. Openssh is on, sendmail is on (but only accepts connects from the local machine), portmap is on and that's about it. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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: Red Hat to support PostgreSQL
Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Even though it may appear that your server is doing a lot, it's not facing > > > the load of a highly scaled enterprise level e-commerce site, where RedHat > > > just doesn't cut it. > > > > That claim is bogus. Red Hat Linux is the number one linux by far in > > enterprise deployments. > > And MS has more enterprise deployments than RH. Does that make MS > better than RH? No, but they aren't a toy either - while they are closed source, and trying to force you to their world as much as possible and restricting freedom (like upgrading your machine when running XP) and a monopolist blatantly using their force in the desktop market to increase adoption of new products (hailstorm, IE, original NT server etc), NT isn't just a toy anymore. All I'm pointing out is that Red Hat Linux does cut in at enterprise level e-commerce cites (we're powering a few of those) - some may not like the product, more don't like Red Hat, but Red Hat Linux is a good and valid alternative. Whether is right for you, depend on your needs, sum you're willing to spend (few things beat Sun Starfire :) and the expertise you have or can build up. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: Red Hat to support PostgreSQL
Alex Knight <[EMAIL PROTECTED]> writes: > 1) Distribution of Linux to have the largest number of "out of the box" > security holes. Check back and look at the security reports. Count them if > you insist. And check for the number of them being Red Hat specific. > > 2) Most commercial software made _for_ RedHat (some companies only > "support" RedHat) insist that you use RPM to install their software, > otherwise you are SOL. Most commercial software made _for_ _Linux_ > supports all distributions. That depends very much on the level of support you're giving - for a big, complex you want to support as few environments as possible. You can use it other places, but won't be supported to the same degree. > 3) So much extra crap running to begin with, eating up extra memory, cpu, > etc. You're obviously unfamiliar with it. > I'm sure we could go on, but this isn't a Linux list :) Agreed. And of course, it isn't very interesting to discuss with someone who is unfamiliar with the product. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: Red Hat to support PostgreSQL
Alex Knight <[EMAIL PROTECTED]> writes: > On Wed, 27 Jun 2001, Lamar Owen wrote: > > > On Wednesday 27 June 2001 16:15, Alex Knight wrote: > > > On Wed, 27 Jun 2001, Lamar Owen wrote: > > > > Disagreed over here, with 4+ years of experience 24x7 on RHL since RHL > > > > 4.1. > > > > > This 4+ years 24/7 experience isn't on that server you said was for > > > internal purposes with low load you mentioned in a previous post, is it? > > > > No. This one has been streaming our RealAudio stream 24x7 since May 1, 1997 > > (minus a few hours for maintenance -- you know, things like replacing failed > > power supplies, replacing/installing hard drives, upgradingthe OS, etc. > > Still running the same Super Micro dual PPro 200 motherboard -- but 192MB now > > instead of the 64MB we started with. ECC, of course. Will be replacing with > > the 'lightly loaded' PIII-600 w/ 1GB as soon as Real Networks supports kernel > > 2.4.) -- along with mail, DNS, and seven domains worth of webservice. Not > > terribly heavy loaded -- but we can and do saturate our T1. > > Even though it may appear that your server is doing a lot, it's not facing > the load of a highly scaled enterprise level e-commerce site, where RedHat > just doesn't cut it. That claim is bogus. Red Hat Linux is the number one linux by far in enterprise deployments. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] Perl-module: Pg
Ludwig Meyerhoff <[EMAIL PROTECTED]> writes: > Remember to actually read the README file ! > please set environment variables POSTGRES_INCLUDE and POSTGRES_LIB ! > Running make test > Make had some problems, maybe interrupted? Won't test > Running make install > Make had some problems, maybe interrupted? Won't install > > cpan> > > > How can I solve that problem? Follow the rather explicit hints. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Red Hat to support PostgreSQL
"Thalis A. Kalfigopoulos" <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, Trond Eivind Glomsrød wrote: > > > "Thalis A. Kalfigopoulos" <[EMAIL PROTECTED]> writes: > > > > > Always a first time for everything bad. Anyway, not wanting to be the > > > pessimist of the bunch, I'll hold my horses and hope that none of my > > > "fears" turns into reality. The issue is that none of the other open > > > source projects RH supported was anything major they could make real > > > money out of, at least not compared to what they can make out of the > > > DB arena. > > > > Uh? The database project is small FTTB (moneywise) compared to other > > things like the kernel, gcc and glibc which are core parts of our base > > product. > > But kernel/gcc/glibc don't comprise a market by themselves. But you called them "not major" and something we couldn't make money from. We make quite a bit of money on gcc, to give one example - through contracts to add features, support for architectures, support etc. We are the number one company in that area (remember, Cygnus is now part of Red Hat). > They are just components of the OS market as a whole (if there is any such > thing left anyway). But the core on which the rest is built. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Red Hat to support PostgreSQL
"Thalis A. Kalfigopoulos" <[EMAIL PROTECTED]> writes: > Always a first time for everything bad. Anyway, not wanting to be the > pessimist of the bunch, I'll hold my horses and hope that none of my > "fears" turns into reality. The issue is that none of the other open > source projects RH supported was anything major they could make real > money out of, at least not compared to what they can make out of the > DB arena. Uh? The database project is small FTTB (moneywise) compared to other things like the kernel, gcc and glibc which are core parts of our base product. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: select to combine 2 tables
"Thomas T. Thai" <[EMAIL PROTECTED]> writes: > On Fri, 22 Jun 2001, Tom Lane wrote: > > > "Thomas T. Thai" <[EMAIL PROTECTED]> writes: > > >> Use a union query: > > >> > > >> select rec_id, path, '' as link, name from cat_cat > > >> UNION > > >> select rec_id, path, link, name from cat_alias > > > > > there is no way to do this in a generic DBI way? i need for this to work > > > across diff kind of DBs. > > > > Huh? That *is* the generic, fully-SQL-standard way. > > the project i'm doing this for is opensource and i need it to work in both > postgresql and mysql. the above statement wouldn't work in mysql. MySQL isn't close to SQL compatible. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Re:7.1.2-4PGDG RPMset uploading.
Lamar Owen <[EMAIL PROTECTED]> writes: > A set for Red Hat 7.0 is uploading right now, and 6.2 and 7.1 sets are up. > /pub/binary/v7.1.2/RPMS on your favorite mirror. This set of RPMs with some further fixes can be found as an SRPM and as binary packages for Red Hat Linux 7.1 at http://people.redhat.com/teg/ Feedback appreciated. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] Re: New 7.1.2 RPMS -- 7.1.2-2.PGDG
"Ted" writes: >> Redhat7.0 already has (well my system did - cant remember if it is default > or not) the "redhat binary" of openssl-0.9.5a-14 installed. > The problem with openssl-0.9.5a and the postgresql-7.1.2-2.PGDG.i386.rpm > from the redhat 7.x folder on the ftp mirror is that > this rpm requires libcrypto.so.1 amongst other things (libssl as well). > > Unfortunately redhat 7.0 has only libcrypto.so.0 and therefore you would > require to upgrade to > openssl-0.9.6 (which has libcrypto.so.1) to get the postgresql 7.1.2 rpm's > installed (short of doing a --nodeps I suppose) > > I tried to upgrade my openssl with the openssl-0.9.6-3.i386.rpm from > redhat7.1 (using rpm -Uvh) but no luck as a lot of other rpm's were > depending on libcrypt.so.0 and so on. There is an openssl095a compatiblity package - install that one, in addition to the new packages. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] ORDER BY Problem
Severin Olloz <[EMAIL PROTECTED]> writes:
> Why does Postgresql order the uppercase letters first?
That is locale dependent - if you don't use a proper locale but use
straight ASCII, A...Za...d would be correct. If you set a locale,
you'll get (Aa)(Bb) etc instead, which is the correct way to sort in
human languages.
> I have e.g. a table with one row an in this row there are follow values:
>
> row1
>
> ADC
> aa
> ABC
>
> With this select-syntax
>
> select * from table order by row1
>
> I become this output
>
> ABC
> ADC
> aa
Note that "aa" can give you some surprises anyway... e.g. in
Norwegian, "aa" is mapped to "å", the last character in the alphabet
(in Norwegian words, not foreign names etc... this distinction is
obviously rather hard to sort by for computers:).
Note that not using locales also makes "ORDER BY" give other bogus
results - as ASCII (or latin1) doesn't know the local alphabets, it
can't sort according to them. Example, for Norwegian:
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 invalid result is what you'll get if you run postgresql without
locale information, so make sure you set one before you initialize the
database and run the postmaster.
--
Trond Eivind Glomsrød
Red Hat, Inc.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] 7.1.2 packaging
Lamar Owen <[EMAIL PROTECTED]> writes: > On Monday 04 June 2001 10:56, Trond Eivind Glomsrød wrote: > > Lamar Owen <[EMAIL PROTECTED]> writes: > > > On Sunday 03 June 2001 13:05, Trond Eivind Glomsrød wrote: > > > > "Tim Mickol" <[EMAIL PROTECTED]> writes: > > > > > any word on 7.1.2 in RPM or SRPM form? > > > > An SRPM can be found at http://people.redhat.com/teg/pg/ > > > > NOTE: > > > While Trond's SRPM is very good (and will be used for pieces in the PGDG > > > SRPM release), do note that Trond's scripts and spec file both use > > > features of latest RedHat releases, which my RPM's may or may not use. > > > There shouldn't bee much there which is Red Hat specific... > > There is comments on the top of the file which break some early > > versions of rpm v3 (newer versions of RPM should be run on all > > supported versions of Red Hat Linux anyway). Other than that, > > reference to Red Hat specific files (like /etc/sysconfig/i18n) are > > conditional. > > In the initscript the use of gettext()? This isn't called directly. > The use of the Red Hat init functions success and kin? OK, these can be found on more than Red Hat Linux. There are also some attempts at workarounds for other distributions. > At one point the spec file wouldn't build to completion on Red Hat 6.1 -- > which, at the time, I was supporting, due to the use of a libtool fileset > that didn't exist in 6.1. This has been fixed... -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] 7.1.2 packaging
Lamar Owen <[EMAIL PROTECTED]> writes: > On Sunday 03 June 2001 13:05, Trond Eivind Glomsrød wrote: > > "Tim Mickol" <[EMAIL PROTECTED]> writes: > > > any word on 7.1.2 in RPM or SRPM form? > > > An SRPM can be found at http://people.redhat.com/teg/pg/ > > NOTE: > While Trond's SRPM is very good (and will be used for pieces in the PGDG SRPM > release), do note that Trond's scripts and spec file both use features of > latest RedHat releases, which my RPM's may or may not use. There shouldn't bee much there which is Red Hat specific... There is comments on the top of the file which break some early versions of rpm v3 (newer versions of RPM should be run on all supported versions of Red Hat Linux anyway). Other than that, reference to Red Hat specific files (like /etc/sysconfig/i18n) are conditional. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Compiling to RPM setup/filesystem layout
"Steve Wolfe" <[EMAIL PROTECTED]> writes: > > Running rpm -ql on the RPMset is too much of a hassle, right? Removing > > all traces of the RPMset is easier than removing all traces of a from-source > > install. > >Really? > > Let's compare removing the RPM's: rpm -e `rpm -qa |grep postgresql` [...] > #rpm --erase php-pgsql-3.0.15-2 That's not what you're doing for your manual install... > rm -rf ~postgres/* So postgres doesn't install it's binaries in /usr/local/bin, libraries in /usr/local/lib etc? -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Fresh Installation of 7.1.1 RPMs = no binding to a port
Lamar Owen <[EMAIL PROTECTED]> writes: > I have considered making the default back to TCP/IP listening I think that's a bad idea, for the "be secure by default" reason. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] "pg_ctl restart" in 7.1.2
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Trond Eivind Glomsrød writes: > > > "pg_ctl restart" seems to not work as documented in postgresql 7.1.2. > > > > bash-2.04$ /usr/bin/pg_ctl restart -w -D /var/lib/pgsql/data -m fast > > waiting for postmaster to shut down..done > > postmaster successfully shut down > > /usr/bin/postmaster: invalid argument -- '-D' > > Try '/usr/bin/postmaster --help' for more information. > > waiting for postmaster to > > startfailed > > pg_ctl: postmaster does not start > > bash-2.04$ > > There was a bug related to this fixed in 7.1.2. I think you are trying to > restart with 7.1.2 pg_ctl an installation that was initially started with > 7.1.1 or earlier, or vice versa. I guess that doesn't work. :-( No, this is 7.1.2 fresh install. I'm working with the initscripts in the rpm dist to make it work with locales properly, as the current 7.1 way of setting "C" gives invalid results for Norwegian and others. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Too Many Open Files PG 7.1
[EMAIL PROTECTED] writes: > Some times on PG 7.1 under heavy load pg complains that there are too > many open files. I am running it under RedHat Linux 7.1 on the 2.4 > kernel. Is this just a matter of needing to increase the maxfiles in > proc/sys/fs? Check what is using the fds - I'm not aware of any generic leaks. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Ideal hardware configuration for pgsql/Netra
GH <[EMAIL PROTECTED]> writes: > Somebody claimed that my post was uninformed...yet RedHat is all of Linux > now? No, of course not. Red Hat is more than Linux, Linux is more than our version of it: Red Hat Linux. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Ideal hardware configuration for pgsql
Michelle Murrain <[EMAIL PROTECTED]> writes: > On Thursday 03 May 2001 11:58 am, Trond Eivind Glomsrød wrote: > > GH <[EMAIL PROTECTED]> writes: > > > On Wed, May 02, 2001 at 08:07:04PM +0100, some SMTP stream spewed forth: > > > > I only have experience with Red Hat, Solaris 8 (intel), and LinuxPPC. > > > > What do you see as the downside of running Red Hat? My intention is to > > > > run RH 7.1, although I can surely be swayed if you can offer some > > > > compelling FreeBSD benefits. > > > > > > FreeBSD is out-of-the-box more secure, more stable, and generally more > > > enjoyable to work with than RedHat. > > > > Hardly. Now, could you stop your uniformed flamebaiting please? > > FreeBSD is nice in some respects (and not in others), but coming with > > FUD like you are doesn't do anyone any good. > > I hate to say it but saying that FreeBSD might be better than Red Hat is > hardly flamebait or FUD. Those others, like "stable" and "secure". "Enjoyable" is obviously subjective (FreeBSD isn't very enjoyable for me, who has used Linux and Solaris extensively and much prefer SysV to BSD). -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Installing in SuSE 7.1
Martín Marqués <[EMAIL PROTECTED]> writes: > On Jue 03 May 2001 22:51, Trond Eivind Glomsrød wrote: > > Bill Barnes <[EMAIL PROTECTED]> writes: > > > Does anyone know of a package for 7.0.3 or 7.1 that > > > will install in SuSE's latest release. > > > > > > How about the Red Hat 7.1 RPMS? > > > > Try? They require glibc 2.2, but AFAIK the newest SuSE release has this. > > Maybe the libs would pass OK, but (at least this happend to me with 7.0.x) > when trying to install the rpm on SuSE, it asks for chkconfig, which the damn > SuSE distro dosn't have. You can download and install that package too :) -- Trond Eivind Glomsrød Red Hat, Inc. ---(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
Lamar Owen <[EMAIL PROTECTED]> writes: > Trond Eivind Glomsrød 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 Of course not, it's not a bug - if this is a problem, it's a bug in Postgresql: [teg@halden teg]$ cat foo2.txt Ad ae ac [teg@halden teg]$ sort foo2.txt ac Ad ae [teg@halden teg]$ > 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 I built it into our trees with a release number < 1 until I've confirmed that this doesn't break other languages. Sorting in the "C" order isn't acceptable for non-English languages as the order is wrong. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] 7.1 RPM has old JDBC driver - SQL statement too long
Lamar Owen <[EMAIL PROTECTED]> writes: > 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. I'll create some jars and mail them to you. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] locale & glibc 2.2.2
Lamar Owen <[EMAIL PROTECTED]> writes: > 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. What exactly is claimed to be broken? If this is the case sensitivity issue, that would count as a postgresql bug. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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 installation problem
Alexander Jerusalem <[EMAIL PROTECTED]> 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? Install the readline2.2.1-2.2.1-2 rpm (which comes with Red Hat Linux 7 - look on your CD or ftp mirror) for backwards compatibility. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Large files on linux
Fernan Aguero <[EMAIL PROTECTED]> 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 do not know if this is kernel > related, filesystem related or both. > > I am researchiing the issue (having some trouble to find info) and found > that there are several alternatives. Can you give me advice for/against the > ones you think are best/worse. Also, if you happen to have links to other > places which might have information on this issue, please pass them along. > > Here are my options: > > i) patch the kernel. > I didn't find much information about this one. I don't know yet whether > this is a kernel related limitation or filesystem-related or both. I have > also read that programs had to be patched to use this 'large_file' patch. > Will probably avoid this one. > > ii) try a new kernel, 2.4-test > have to do some research into this yet, but apparently the new linux kernel > will support large files. My understanding right now is that ext2fs do not > support files this large, It does. > iii) try a new filesystem. > several filesystems appear to support large files (but not ext2fs, and > apparently not ext3fs) On 2.2, it's VFS related. ext3/ext2 doesn't have such problems. Red Hat Linux 7.0 includes a kernel (the "enterprise" one) with the LFS patched included and test. It's also ready for 2.4 -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Can PostGreSQL handle 100 user database?
Marc SCHAEFER <[EMAIL PROTECTED]> writes: > On Thu, 30 Nov 2000, The Hermit Hacker wrote: > > > Note that this is a Linux limitation ... and even then, I'm not quite sure > > how accurate that is anymore ... the *BSDs have supported >2gb file > > systems for ages now, and, since IBM supports Linux, I'd be shocked if > > there was a 2GB limit on memory, considering alot of IBMs servers support > > up to 4 or 8GB of RAM ... > > Linux 2.2.x on ix86 only supports files upto 2 GB. This support has been backported as is available in some kernels shipped with Red Hat Linux, and has been so for some time. Possibly others. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] PostgreSQL on RedHat High Availability Server.
Ralph Allan Rice <[EMAIL PROTECTED]> writes: > Anyone out there used PostgreSQL on Redhat's High Availability Server? > We are trying to determine if a RedHat/PostgreSQL combo could be used in > a dual-redundant manner, such as a Active/Inactive cluster > configuration. Anyone out there do this? Any problems, gripes, or > success stories? Please respond to ralph AT pcioh.com. Thank you. The obvious problem would be that these databases aren't synchronized. I all you wanted to was read data, it should work just fine. If not, you need to make your programs aware of the fact you're running on multiple machines and update all of the databases - and handle the situation that one may be down, and needs to be updated before going online again. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] postgres on redhat 7.0
"Adam Lang" <[EMAIL PROTECTED]> writes: > But it don't help if you downloaded the OS. ;) You can of course find it on the ftp site as well, in the RPMS directory. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] --enable-syslog in rh7 ?
"Sergio A. Kessler" <[EMAIL PROTECTED]> writes: > hi teg, > > the build of postgressql 7.0.2 in rh7 was with --enable-syslog ? No, but this is part of a configuration patch: * USE_SYSLOG: use syslog for elog and error messages printed by tprintf @@ -169,7 +169,7 @@ * (syslog=0 for stdio, syslog=1 for stdio+syslog, syslog=2 for syslog). * For information see backend/utils/misc/trace.c (Massimo Dal Zotto). */ -/* #define USE_SYSLOG */ +#define USE_SYSLOG -- Trond Eivind Glomsrød Red Hat, Inc.
[GENERAL] 7.0 vs. 7.1 (was: latest version?)
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On Wed, 25 Oct 2000, Holger Klawitter wrote: > > > Pawel Wegrzyn wrote: > > > > > > Hi, > > > What is the latest version of PostgreSQL? > > > Is there something like 7.1? > > > > The most recent version 7.0.2. 7.1 is about to come - I am looking > > forward to it as well. > > 7.0.3 is about to come out, 7.1 is about 2 months away yet :) 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? The reason I'm asking is that Red Hat wants to maintain binary compatibility in a for all x in y.x (that's what distribution numbering means to us, other Linux distributions have other (and sometimes rather weird) schemes), but I'm also interested in upgrading the database component. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
Peter Eisentraut <[EMAIL PROTECTED]> writes: > But claiming that you can't upgrade is painting over what might rather be > a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file > like this: > > %preupgrade > pg_dumpall >somewhere 1) You don't know that postgresql is running. It probably isn't. 2) You don't know that you have the diskspace to do that. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
"Efrain Caro" <[EMAIL PROTECTED]> writes: > Forgive my ignorance. What is this no-upgrade policy issue about? That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to 7.1 Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
Jeff Hoffmann <[EMAIL PROTECTED]> writes: > > >>> "Alfredo" <[EMAIL PROTECTED]> 09/29/00 12:28PM >>> > > I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if > > yes, anybody know why? > > i think the thing is that they added mysql because it's now GPL'd -- it > wasn't in there before because it wasn't really "free" software. > postgres (7.0.2) is indeed still in redhat 7, but with some of the > comments on the list about the RPMs, it's possible that it may not stay > as part of the distribution because of upgrading issues. I've never said or indicated that. That said, I dislike the current no-upgrade policy. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
"Adam Lang" <[EMAIL PROTECTED]> writes: > Not to mention the fact that PHP 4 installs with MySQL support native. While we have a MySQL module for PHP, we also have a pgsql module. > If RedHat did do MySQL by default, technically Apache, PHP, and MySQL would > be a pretty straightforward Web Serving bundle. So is Postgresql, PHP and Apache - no MySQL necesarry. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
"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. 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. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] 7.1 Release Date
Tom Lane <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: > > Will there be a clean upgrade path this time, or > > yet another dump-initdb-restore procedure? > > Still TBD, I think --- right now pg_upgrade would still work, but if > Vadim finishes WAL there's going to have to be a dump/reload for that. > > Another certain dump/reload in the foreseeable future will come from > adding tablespace support/changing file naming conventions. > > > Unclean upgrades are one of major disadvantages of postgresql FTTB, > > IMHO. > > You can always stick to Postgres 6.5 :-). There are certain features > that just cannot be added without redoing the on-disk table format. > I don't think we will ever want to promise "no more dump/reload"; > if we do, it will mean that Postgres has stopped improving. Not necesarrily - one could either design a on disk format with room for expansion or create migration tools to add new fields. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] 7.1 Release Date
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote: > > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > > > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote: > > > > > > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > > > > > > > On Mon, 28 Aug 2000, Miguel Omar Carvajal wrote: > > > > > > > > > > > Hi there, > > > > > >When will Postgresql 7.1 be released? > > > > > > > > > > right now, we're looking at October-ish for going beta, so most likely > > > > > November-ish for a release ... > > > > > > > > Will there be a clean upgrade path this time, or > > > > yet another dump-initdb-restore procedure? > > > > > > IMHO, upgrading a database server is like upgrading an operating system > > > ... you scheduale downtime, back it all up and upgrade ... > > > > The problem is, this doesn't play that well with upgrading the > > database when upgrading the OS, like in most Linux distributions. > > why not? pg_dump;pkrm old;pkadd new;load ... no? Because the system is down during this upgrade - the database isn't running. Also, automated dump might lead to data loss if space becomes an issue. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] 7.1 Release Date
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On Mon, 28 Aug 2000, Miguel Omar Carvajal wrote: > > > Hi there, > >When will Postgresql 7.1 be released? > > right now, we're looking at October-ish for going beta, so most likely > November-ish for a release ... Will there be a clean upgrade path this time, or yet another dump-initdb-restore procedure? Unclean upgrades are one of major disadvantages of postgresql FTTB, IMHO. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] 7.1 Release Date
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On 29 Aug 2000, Trond Eivind [iso-8859-1] Glomsr d wrote: > > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > > > On Mon, 28 Aug 2000, Miguel Omar Carvajal wrote: > > > > > > > Hi there, > > > >When will Postgresql 7.1 be released? > > > > > > right now, we're looking at October-ish for going beta, so most likely > > > November-ish for a release ... > > > > Will there be a clean upgrade path this time, or > > yet another dump-initdb-restore procedure? > > IMHO, upgrading a database server is like upgrading an operating system > ... you scheduale downtime, back it all up and upgrade ... The problem is, this doesn't play that well with upgrading the database when upgrading the OS, like in most Linux distributions. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] PG 7.0.2 Install
"Darrin Ladd" <[EMAIL PROTECTED]> writes: > I am trying to install 7.0.2 on an alpha box running Red Hat Linux 6.2. I > was told that the 7.0.2 rpm's have an alpha patch in them and that would be > the best bet for success. Yet, I have run into a little problem. When I > try to install the rpm (rpm -i postgresql-7_0_2-2_i386.rpm) You obviously can't install postgresql binary RPMs for Intel on an Alpha - get the SRPM and do a rpm --rebuild of it. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL]
Lee Johnson <[EMAIL PROTECTED]> writes: > 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 is more of a competitor to Microsoft's SQL server than Microsoft Access. It's a server, and doesn't have the equivalent GUI functionality of Access. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
[EMAIL PROTECTED] (Jan Wieck) writes: > Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > Trond Eivind Glomsrød wrote: > > > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > > > > > Trond Eivind Glomsrød wrote: > > > > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > > > > commercial spawns which may leverage the code. > > > > > > > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > > > > the source along. > > > > > > > > > > So if someone offers $$$ for implementation of Postgres > > > > > feature XYZ I don't have to make that code open source? > > > > > > > > You don't have to tell the world they can have it for free - you can > > > > sell it, and develop it by demand. > > > > > > > > > Only need to ship the code to the one paying > > > > > > > > Yes. > > > > > > Now I don't want to ship the source code. My customer would > > > be happy with a patched 8.2.3 binary as long as I'm > > > responsible to patch future versions until I release the > > > sources. Is that OK? > > > > You don't have to give the customer the source, as long as you > > gurantee that he gets it (for cost of distribution) if he wants it. > > Wordy, but how can I prevent him to ask for? By doing everything he wants (and perfect) so he doesn't have a need for it? Basically, GPL is intended to protect the end user and guaranteeing him the source if he wants it - and that he can do what he wants to with it, as long as he doesn't prevent others from doing so. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
[EMAIL PROTECTED] (Jan Wieck) writes: > Trond Eivind Glomsrød wrote: > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > Trond Eivind Glomsrød wrote: > > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > > commercial spawns which may leverage the code. > > > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > > the source along. > > > > > > So if someone offers $$$ for implementation of Postgres > > > feature XYZ I don't have to make that code open source? > > > > You don't have to tell the world they can have it for free - you can > > sell it, and develop it by demand. > > > > > Only need to ship the code to the one paying > > > > Yes. > > Now I don't want to ship the source code. My customer would > be happy with a patched 8.2.3 binary as long as I'm > responsible to patch future versions until I release the > sources. Is that OK? You don't have to give the customer the source, as long as you gurantee that he gets it (for cost of distribution) if he wants it. -- Trond Eivind Glomsrød Red Hat, Inc.
