Thread: Red Hat to support PostgreSQL
Here is a press release stating Red Hat will offer commercial support
for PostgreSQL:
http://www.redhat.com/about/presscenter/2001/press_database.html
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
--- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Here is a press release stating Red Hat will offer commercial > support > for PostgreSQL: > > > http://www.redhat.com/about/presscenter/2001/press_database.html Is RedHat simply providing PostgreSQL support or are they placing developers to work on enhancements/bug fixes as well? Brent __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
> --- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > Here is a press release stating Red Hat will offer commercial > > support > > for PostgreSQL: > > > > > > > http://www.redhat.com/about/presscenter/2001/press_database.html > > Is RedHat simply providing PostgreSQL support or are they > placing developers to work on enhancements/bug fixes as well? They are placing developers too. New people. I assume they will announce something here today. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Brent R. Matzelle" <bmatzelle@yahoo.com> writes: > --- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > Here is a press release stating Red Hat will offer commercial > > support > > for PostgreSQL: > > > > > > > http://www.redhat.com/about/presscenter/2001/press_database.html > > Is RedHat simply providing PostgreSQL support or are they > placing developers to work on enhancements/bug fixes as well? Yes, we will/are working on enhancements for PostgreSQL. -- Trond Eivind Glomsrød Red Hat, Inc.
What they'll probably do is write a fancy-schmancy installer and call it
"The Redhat Database", since that's been business plan with other all
"their" other software..... Just kidding RH guys *grin*...
Since the same people who backed (and are backing?) Redhat started and
own Greatbridge, I'm not at all surprised to see RH start to openly support
PostgreSQL.. All good for PostgreSQL in the end, I think...
-Mitch
----- Original Message -----
From: "Brent R. Matzelle" <bmatzelle@yahoo.com>
To: "PostgreSQL-general" <pgsql-general@postgresql.org>
Sent: Monday, June 25, 2001 10:47 AM
Subject: Re: [GENERAL] Red Hat to support PostgreSQL
> --- Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> > Here is a press release stating Red Hat will offer commercial
> > support
> > for PostgreSQL:
> >
> >
> >
> http://www.redhat.com/about/presscenter/2001/press_database.html
>
> Is RedHat simply providing PostgreSQL support or are they
> placing developers to work on enhancements/bug fixes as well?
>
> Brent
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
On Mon, 25 Jun 2001, Bruce Momjian wrote: > > --- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > Here is a press release stating Red Hat will offer commercial > > > support > > > for PostgreSQL: > > > > > > > > > > > http://www.redhat.com/about/presscenter/2001/press_database.html > > > > Is RedHat simply providing PostgreSQL support or are they > > placing developers to work on enhancements/bug fixes as well? > > They are placing developers too. New people. I assume they will > announce something here today. Yes, but are they going to be collaborating closely with the current Pg core devel team or are they going to work on theirown? The concern is regarding the Cnet article about "Redhat forking off eventually with their own pg". Their representativesaid that there is not such intention but given that "verba volant, scripta manent", what are the guaranteesagainst that? It would really spoil my day to have GM'ed Postgresqls running around. I can barely keep up with one, let alone two ;-) cheers, thalis > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
> On Mon, 25 Jun 2001, Bruce Momjian wrote: > > > Is RedHat simply providing PostgreSQL support or are they > > > placing developers to work on enhancements/bug fixes as well? > > > > They are placing developers too. New people. I assume they will > > announce something here today. > > Yes, but are they going to be collaborating closely with the > current Pg core devel team or are they going to work on their > own? The concern is regarding the Cnet article about "Redhat > forking off eventually with their own pg". Their representative > said that there is not such intention but given that "verba > volant, scripta manent", what are the guarantees against that? Well, I don't know Red Hat has done forking in any other open source project, so I don't see why it would happen here. Yes, technically, they can fork it, but so can anyone else. The BSD license concept is that a company could not possibly duplicate the effectiveness of the open source community, so why would any company try. > It would really spoil my day to have GM'ed Postgresqls running > around. I can barely keep up with one, let alone two ;-) That is exactly it. No one could keep up with us in a forked branch of our code, and if they could, we would not be doing our jobs and maybe the fork would be a good thing. The biggest fork I can remember was from Jolitz's 386/BSD project. Jolitz was clearly keeping it all to himself and not doing anything to advance the code. The NetBSD fork was clearly a good thing. I am not saying anything about PostgreSQL forking. What I am saying is that as long as we are healthy, no one can fork effectively, and this is true of all open-source projects. In fact, we have advanced so quickly in comparison to other open-source databases _because_ we are so healthy. If we ever get closed-minded, insulting, non-inclusive, or rude, you guys better kick us in the butts. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Hi all, My thought on this is that Red Hat will do the following : a) Gain entry into a profitable, growing market segment with their product b) Enhance PostgreSQL's profile through their work c) Assist in more people developing with and for PostgreSQL, both through Red Hat's people and through others adding support for "Red Hat Database" to their products c.a) More bugs fixed c.b) More features added c.c) Further improved documentation c.d) Improve the present database design, management and development tools. Sybase, Oracle, Informix benefit from them. We will too. At some point they'll probably provide some direction into the PostgreSQL effort too. Nothing wrong with this as long as it's to the benefit of PostgreSQL users (not just "Red Hat Database" users) and generally acceptable. I think their input should be encouraged, just not taken verbatim. So, I reckon it's a great thing to have more people involved with PostgreSQL. The PostgreSQL community is strong, and should not be scared of this. :-) Regards and best wishes, Justin Clift "Thalis A. Kalfigopoulos" wrote: > > On Mon, 25 Jun 2001, Bruce Momjian wrote: > > > > --- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > > Here is a press release stating Red Hat will offer commercial > > > > support > > > > for PostgreSQL: > > > > > > > > > > > > > > > http://www.redhat.com/about/presscenter/2001/press_database.html > > > > > > Is RedHat simply providing PostgreSQL support or are they > > > placing developers to work on enhancements/bug fixes as well? > > > > They are placing developers too. New people. I assume they will > > announce something here today. > > Yes, but are they going to be collaborating closely with the current Pg core devel team or are they going to work on theirown? The concern is regarding the Cnet article about "Redhat forking off eventually with their own pg". Their representativesaid that there is not such intention but given that "verba volant, scripta manent", what are the guaranteesagainst that? > > It would really spoil my day to have GM'ed Postgresqls running around. I can barely keep up with one, let alone two ;-) > > cheers, > thalis > > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Mon, 25 Jun 2001, Bruce Momjian wrote: > > On Mon, 25 Jun 2001, Bruce Momjian wrote: > > > > Is RedHat simply providing PostgreSQL support or are they > > > > placing developers to work on enhancements/bug fixes as well? > > > > > > They are placing developers too. New people. I assume they will > > > announce something here today. > > > > Yes, but are they going to be collaborating closely with the > > current Pg core devel team or are they going to work on their > > own? The concern is regarding the Cnet article about "Redhat > > forking off eventually with their own pg". Their representative > > said that there is not such intention but given that "verba > > volant, scripta manent", what are the guarantees against that? > > Well, I don't know Red Hat has done forking in any other open source > project, so I don't see why it would happen here. > Always a first time for everything bad. Anyway, not wanting to be the pessimist of the bunch, I'll hold my horses and hopethat none of my "fears" turns into reality. The issue is that none of the other open source projects RH supported wasanything major they could make real money out of, at least not compared to what they can make out of the DB arena. Hopefully,even if things don't turn out exactly as expected, they will have benefited Pg a lot by then. > That is exactly it. No one could keep up with us in a forked branch of > our code, and if they could, we would not be doing our jobs and maybe > the fork would be a good thing. I fear not the technical part...I fear the marketing part. This is were battles are won today (sad but true). > In fact, we have advanced so quickly in comparison to other open-source > databases _because_ we are so healthy. If we ever get closed-minded, > insulting, non-inclusive, or rude, you guys better kick us in the butts. Hopefully I won't have to look for my spiked shoes anytime soon >-) Just to lighten up here, I read the following in an article: 'Three months ago, IBM rented a billboard near Oracle's Silicon Valley headquarters declaring a "search for intelligent software,"only to find, a few days later, that an Oracle billboard reporting "Then you've come to the right place. Oracle,"had been put up.' cheers, thalis > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? >
"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> 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.
On 25 Jun 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> 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. > But kernel/gcc/glibc don't comprise a market by themselves. They are just components of the OS market as a whole (if thereis any such thing left anyway). Whereas PostgreSQL is one product part of one market, the DBMS market. So forking offjust this one thing will mean stepping in for a market's share which is indeed big $$$. This couldn't be the case withgnome or gcc. I'm not comparing sizes. Just strategic importance :^) --thalis
"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes: > On 25 Jun 2001, Trond Eivind Glomsrød wrote: > > > "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> 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.
On 25 Jun 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes: > > > On 25 Jun 2001, Trond Eivind Glomsr�d wrote: > > > > > "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> 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. I may use a ladder to gather cashew nuts of a tree. They are expensive. That doesn't necessarily mean that ladders are expensivealthough this may bring some value to their market :o) cheers, thalis > -- > Trond Eivind Glomsr�d > Red Hat, Inc. >
> Yes, but are they going to be collaborating closely with the > current Pg core devel team or are they going to work on their > own? The concern is regarding the Cnet article about "Redhat > forking off eventually with their own pg". Their representative > said that there is not such intention but given that "verba > volant, scripta manent", what are the guarantees against that? > > It would really spoil my day to have GM'ed Postgresqls running > around. I can barely keep up with one, let alone two ;-) Well, if they fork then we can probably assume Redhat's database will be as bad as their OS, so there's nothing to worry about ;-) *chuckle* - Andrew
On Tue, 26 Jun 2001, Andrew Snow wrote: > > > Yes, but are they going to be collaborating closely with the > > current Pg core devel team or are they going to work on their > > own? The concern is regarding the Cnet article about "Redhat > > forking off eventually with their own pg". Their representative > > said that there is not such intention but given that "verba > > volant, scripta manent", what are the guarantees against that? > > > > It would really spoil my day to have GM'ed Postgresqls running > > around. I can barely keep up with one, let alone two ;-) > > Well, if they fork then we can probably assume Redhat's database will be as > bad as their OS, so there's nothing to worry about ;-) *chuckle* That's not true. If you started off with Ygdrassil linux then probably Rh seems too "soft", but they are the ones who broughtthe crowds closer. And although technical expertise may be desired from "the followers", it is the numbers that makethe difference and the people vote for u.s.e.r.f.r.i.e.n.d.l.y. I don't think Volkerding for example would be even remotelyinterested in doing market research ;-) Besides Rh does more than just bundle a linux distribution together. Anyway, there are Rh members on the list. They know better what Rh has contributed (probably more than we know of) cheers, thalis > > > - Andrew > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
Thalis A. Kalfigopoulos wrote: >>> >>Well, if they fork then we can probably assume Redhat's database will be as >>bad as their OS, so there's nothing to worry about ;-) *chuckle* >> > > That's not true. If you started off with Ygdrassil linux then probably Rh seems too "soft", but they are the ones who broughtthe crowds closer. And although technical expertise may be desired from "the followers", it is the numbers that makethe difference and the people vote for u.s.e.r.f.r.i.e.n.d.l.y. I don't think Volkerding for example would be even remotelyinterested in doing market research ;-) Besides Rh does more than just bundle a linux distribution together. > Anyway, there are Rh members on the list. They know better what Rh has contributed (probably more than we know of) In 1997 I bought a 6 CD set from Info Magic. RedHat was on disk one. I installed it because it was on disk one... I had a machine running Suse for a while because of ISDN support. I have installed various other distribs in a VMware machine to test them. There is nothing very wrong with RedHat. For a server it needs to be hardened a little, but that is no big deal. On the Power tools disk in that set there was Postgresql. Having read the then non free licence of mySql I installed Postgresql. Yes things really are that simple out here in user land. Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
Quoting Tony Grant (tony@animaproductions.com): > In 1997 I bought a 6 CD set from Info Magic. RedHat was on disk one. I > installed it because it was on disk one... I had a machine running Suse In 1996-97, I had just been through the horror of upgrading a lab full of machines from SLS 1.03 to Slackware, and then from one Slackware version to another. Each "upgrade" was a re-install and reconfigure. Along came RedHat with the promise of doing real upgrades without losing all your configuration. Of course I jumped at the chance. I've been using RedHat ever since, even though they had a couple of major changes in rpm that made it impossible to do a real upgrade. In 2000, I had an PHP application written using MySQL, and I suddenly decided I wanted to be able to have it work better with simultaneous updates, and I'd read that Postgresql was no longer dog slow compared to MySQL, so I switched to PostgresSQL. -- Paul Tomblin <ptomblin@xcski.com>, not speaking for anybody "What we perceive as `God' is simply a by-product of our search for God." - G'Kar.
Quoting Paul Tomblin (ptomblin@xcski.com):
> In 1996-97, I had just been through the horror of upgrading a lab full of
Sorry, that was 1991-92. What was I thinking?
> machines from SLS 1.03 to Slackware, and then from one Slackware version
--
Paul Tomblin <ptomblin@xcski.com>, not speaking for anybody
"How do you feel about women's rights?"
"I like either side of them."
-- Groucho Marx, 1890-1977
>>>>> "BM" == Bruce Momjian <pgman@candle.pha.pa.us> writes: BM> Here is a press release stating Red Hat will offer commercial support BM> for PostgreSQL: BM> http://www.redhat.com/about/presscenter/2001/press_database.html My read is that they're supporting their integrated OS+DB package, not PostgreSQL directly. This is not the same in my book, since I don't care to run RHL in any kind of production environment. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
On 27 Jun 2001, Vivek Khera wrote: > >>>>> "BM" == Bruce Momjian <pgman@candle.pha.pa.us> writes: > > BM> Here is a press release stating Red Hat will offer commercial support > BM> for PostgreSQL: > > BM> http://www.redhat.com/about/presscenter/2001/press_database.html > > My read is that they're supporting their integrated OS+DB package, not > PostgreSQL directly. This is not the same in my book, since I don't > care to run RHL in any kind of production environment. Agreed over here. -knight
On Wednesday 27 June 2001 15:35, Alex Knight wrote: > On 27 Jun 2001, Vivek Khera wrote: > > This is not the same in my book, since I don't > > care to run RHL in any kind of production environment. > Agreed over here. Disagreed over here, with 4+ years of experience 24x7 on RHL since RHL 4.1. And what about the SPECweb99 record just set by TUX on RHL 7.1 by an IBM server? :-) All indications the reports have given is that the RedHat Database code is going to be open-source -- now, as to what license their modifications will be released under is anybody's guess -- but my educated guess would be the same old PostgreSQL license we know and love, with a minor addition to the copyright notice that 'Portions Copyright Red Hat Software, Inc.' Thus the PostgreSQL Global Development Group would be free to incorporate such modifications if we so saw fit to do so. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
<snip> ...This is not the same in my book, since I don't care to run RHL in any kind of production environment... <snip> What is it about RHL that various people wouldn't recommend running it in a production envornment? I don't have a contrary view, so much as I'd like to know what's specifically wrong with the RH distribution. We're trying to decide on a distribution on which to develop telecom software, utilizing PostgreSQL of course :-) What other distributions would you recommend and why? Tim ----- Original Message ----- From: "Alex Knight" <knight@phunc.com> To: "Vivek Khera" <khera@kcilink.com> Cc: <pgsql-general@postgresql.org> Sent: Wednesday, June 27, 2001 12:35 PM Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL > On 27 Jun 2001, Vivek Khera wrote: > > > >>>>> "BM" == Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > BM> Here is a press release stating Red Hat will offer commercial support > > BM> for PostgreSQL: > > > > BM> http://www.redhat.com/about/presscenter/2001/press_database.html > > > > My read is that they're supporting their integrated OS+DB package, not > > PostgreSQL directly. This is not the same in my book, since I don't > > care to run RHL in any kind of production environment. > > Agreed over here. > > -knight > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl >
On Wed, 27 Jun 2001, Lamar Owen wrote: > On Wednesday 27 June 2001 15:35, Alex Knight wrote: > > On 27 Jun 2001, Vivek Khera wrote: > > > This is not the same in my book, since I don't > > > care to run RHL in any kind of production environment. > > > Agreed over here. > > Disagreed over here, with 4+ years of experience 24x7 on RHL since RHL 4.1. > > And what about the SPECweb99 record just set by TUX on RHL 7.1 by an IBM > server? :-) 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? > All indications the reports have given is that the RedHat Database code is > going to be open-source -- now, as to what license their modifications will > be released under is anybody's guess -- but my educated guess would be the > same old PostgreSQL license we know and love, with a minor addition to the > copyright notice that 'Portions Copyright Red Hat Software, Inc.' Thus the > PostgreSQL Global Development Group would be free to incorporate such > modifications if we so saw fit to do so.
On Wed, 27 Jun 2001, Tim Barnard wrote: > <snip> > ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... > <snip> > > What is it about RHL that various people wouldn't > recommend running it in a production envornment? > I don't have a contrary view, so much as I'd like to > know what's specifically wrong with the RH distribution. > We're trying to decide on a distribution on which to > develop telecom software, utilizing PostgreSQL of > course :-) What other distributions would you > recommend and why? > > Tim Now that they will unite the OS with the DB, I can't think of more suitable environment for the Sys/DB admin's paradise.That is, if they do indeed make significant changes to the operating system they are shipping in the RHDB. cheers, thalis ps. no, i don't personally use Rh. > > ----- Original Message ----- > From: "Alex Knight" <knight@phunc.com> > To: "Vivek Khera" <khera@kcilink.com> > Cc: <pgsql-general@postgresql.org> > Sent: Wednesday, June 27, 2001 12:35 PM > Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL > > > > On 27 Jun 2001, Vivek Khera wrote: > > > > > >>>>> "BM" == Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > > BM> Here is a press release stating Red Hat will offer commercial > support > > > BM> for PostgreSQL: > > > > > > BM> http://www.redhat.com/about/presscenter/2001/press_database.html > > > > > > My read is that they're supporting their integrated OS+DB package, not > > > PostgreSQL directly. This is not the same in my book, since I don't > > > care to run RHL in any kind of production environment. > > > > Agreed over here. > > > > -knight > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://www.postgresql.org/search.mpl > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl >
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. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
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. 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. 3) So much extra crap running to begin with, eating up extra memory, cpu, etc. (Yeah, sure you can spend time securing and setting up the box to not run what it shouldn't be... _OR_ you can save that wasted time (it adds up when you are setting up 30 production machines) and run a quality distribution like Debian or even Slackware) I'm sure we could go on, but this isn't a Linux list :) Now back to our regularly scheduled database discussion. -Knight On Wed, 27 Jun 2001, Tim Barnard wrote: > <snip> > ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... > <snip> > > What is it about RHL that various people wouldn't > recommend running it in a production envornment? > I don't have a contrary view, so much as I'd like to > know what's specifically wrong with the RH distribution. > We're trying to decide on a distribution on which to > develop telecom software, utilizing PostgreSQL of > course :-) What other distributions would you > recommend and why? > > Tim > > ----- Original Message ----- > From: "Alex Knight" <knight@phunc.com> > To: "Vivek Khera" <khera@kcilink.com> > Cc: <pgsql-general@postgresql.org> > Sent: Wednesday, June 27, 2001 12:35 PM > Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL > > > > On 27 Jun 2001, Vivek Khera wrote: > > > > > >>>>> "BM" == Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > > BM> Here is a press release stating Red Hat will offer commercial > support > > > BM> for PostgreSQL: > > > > > > BM> http://www.redhat.com/about/presscenter/2001/press_database.html > > > > > > My read is that they're supporting their integrated OS+DB package, not > > > PostgreSQL directly. This is not the same in my book, since I don't > > > care to run RHL in any kind of production environment. > > > > Agreed over here. > > > > -knight > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://www.postgresql.org/search.mpl > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl >
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. I have a T1 to my house, and I saturate it all the time... without load :) -Knight
> All indications the reports have given is that the RedHat Database code is > going to be open-source -- now, as to what license their modifications will > be released under is anybody's guess -- but my educated guess would be the > same old PostgreSQL license we know and love, with a minor addition to the > copyright notice that 'Portions Copyright Red Hat Software, Inc.' Thus the > PostgreSQL Global Development Group would be free to incorporate such > modifications if we so saw fit to do so. I don't think it is healthy to suggest that RH will be releasing their own custom modifications to the PostgreSQL core server, unless you know something we don't. :-) All indications I have heard are that they will be submitting patches just like everyone else, and will be working on admin tools too. Maybe that is what you were referring to about a separate license. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wednesday 27 June 2001 16:04, Tim Barnard wrote: > <snip> > ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... > <snip> > What is it about RHL that various people wouldn't > recommend running it in a production envornment? 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' :-). The 2.4 Linux kernel is a big win for me -- I saw a factor of two performance increase on the regression suite when I upgraded to kernel 2.4 over 2.2 on the same hardware -- it's nice for the parallel tests to run in 44 seconds on our PIII 600. Not a screamer -- but not a slouch. I think most people that say they'd not run RHL either simply don't like Linux or just don't like Red Hat. Nothing different in this than the attitude of MySQL users who just simply don't like PostgreSQL. Or they've heard that Postgres95 1.01 was a dog, so they won't use PostgreSQL 7.1.2. The same comparison holds for Red Hat -- the number of possible reasons to not use it in a production, 24x7, high-load environment are shrinking with every release. > We're trying to decide on a distribution on which to > develop telecom software, utilizing PostgreSQL of > course :-) What other distributions would you > recommend and why? Any PostgreSQL supported platform is an OK choice. I personally would try to not make it distribution-specific -- you will kick yourself later if you do. Making it PostgreSQL-specific, of course, is not a problem :-). FreeBSD has good support, and runs very well if you're not hung up on using Linux. But I've found RHL just fine for my needs. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> ...This is not the same in my book, since I don't care
> to run RHL in any kind of production environment...
> <snip>
>
> What is it about RHL that various people wouldn't
> recommend running it in a production envornment?
> I don't have a contrary view, so much as I'd like to
> know what's specifically wrong with the RH distribution.
> We're trying to decide on a distribution on which to
> develop telecom software, utilizing PostgreSQL of
> course :-) What other distributions would you
> recommend and why?
Here's my take on it, it may or may not reflect reality. : )
RH didn't get where they are by being the "best", they got there by
being the most "sellable". Early on, they grabbed a large market share by
making a few very sellable decisions, and now, the fact that they are so
large now gives them momentum that keeps them afloat - oddly enough, just
like Microsoft. : ) Because they're large, they garner support in terms of
drivers and programming, and that, in turn, makes them more attractive to
potential users.
Their products aren't necessarily "bad", at least not all of them.
Historically, the .0 releases are buggy and flakey, the .1's are better, and
the .2's are decent. Now that, of course, depends on your own definitions
of such qualitative terms as "buggy" and "decent", but according to my
definitions and experience, that's been about right.
For my needs, they're also becoming extremely bloated. I don't need
three CD's worth of installation crap to get Apache, SSH, and PostgreSQL
running. : ) I also don't like depending on precompiled packages, for a
couple of reasons - including the fact that it's hard to choose compile-time
settings on pre-compiled binaries. : )
So, I've started working on putting together a sort of "mini-distro"
with only what my servers will need. It's quite a bit easier than I thought
it would be, and lets me "mix and match" the features that I want, such as
XFS support and what-not.
Now, since I've been so negative about them, I'll also be positive -
RedHat isn't "bad" for production use. Stay with .2 releases, and things
will likely be just fine for you. There are some policy decisions that
(IMHO) aren't as good as they could be, but those can generally be fixed
with a few minor modifications to startup scripts and configuration files.
As long as you tighten down the security holes in the default installation,
most people would likely be just fine using RedHat on their production
machines.
steve
On Wed, Jun 27, 2001 at 01:43:00PM -0700, Alex Knight wrote:
> 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.
>
> 3) So much extra crap running to begin with, eating up extra memory, cpu,
> etc. (Yeah, sure you can spend time securing and setting up the box to not
> run what it shouldn't be... _OR_ you can save that wasted time (it adds up
> when you are setting up 30 production machines) and run a quality
> distribution like Debian or even Slackware)
I'm just sticking these together because they are really the same issue,
and an administrative one, not engineering.
You can set up your machines however you wish. While I generally prefer
Debian for standalone systems because dselect makes it easy to add and remove
things without spending a lot of time looking for other files, I've found that
recent Red Hat is very manageable, especially if you are building a custom
installation or your own .rpm files.
It all boils down to how much time you want to spend dealing with your
installation and how custom you want it. For a moderate fee, I'll build you a
Red Hat kickstart CD that includes exactly what you want and doesn't start so
much stuff "out of the box". For a lesser fee I'll tell you how. For free,
you can learn. Yes, the default install puts a lot of crap most people don't
want on the system. Defaults are typically not production settings.
> 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.
So?
[Note: this is going to be my only comment on the subject of distributions, since
it is even further away from the scope of this list then the support of
PostgreSQL by Red Hat]
--
Adam Haberlach | "Pancakes don't make hardly any juice
adam@newsnipple.com | and bacon makes too much."
http://www.newsnipple.com | -- bug-eyed earl
'88 EX500 '00 >^< | http://youlook.org
Alex Knight <knight@phunc.com> 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.
On Wed, Jun 27, 2001 at 01:04:27PM -0700, some SMTP stream spewed forth: > <snip> > ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... > <snip> > > What is it about RHL that various people wouldn't > recommend running it in a production envornment? > I don't have a contrary view, so much as I'd like to > know what's specifically wrong with the RH distribution. > We're trying to decide on a distribution on which to > develop telecom software, utilizing PostgreSQL of > course :-) What other distributions would you > recommend and why? None of them. Run FreeBSD. It's better. Redhat (and, well, Linux) is mostly geared toward Desktops. It is supposedly "userfriendly", which just makes it a piece of crap and buggy. If you prefer using things like "RPM" and dealing with GNU crappage and glibc issues all the time, then you probably want to use Linux., possibly in the form of Redhat if you really feel sadistic. gh > Tim
> However, I would be surprized if their shipped RHDB product didn't > incorporate changes that they came up with -- even if the PostgreSQL group > didn't apply them to the base dist. Although I certainly reserve the right > to be wrong. Yes, I know that may not be healthy. Yet they do it now with > the Linux kernel (their 'enterprise' kernel patches, for instance) -- why > would PostgreSQL be any different? That would concern me if it ever happened. GB hasn't done it and I hope RH doesn't either. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Wow, I didn't realize I was going to open such a big can of worms :-)
Thanks to everyone for putting in their "two-cents worth."
All of the responses have definitely been helpful. And I
agree with Adam, et al, this really doesn't belong on this
list so lets end this thread and move on.
Thanks again.
Tim
----- Original Message -----
From: "Tim Barnard" <tbarnard@povn.com>
To: <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL
On 27 Jun 2001, Tim Barnard wrote:
<snip>
...This is not the same in my book, since I don't care
to run RHL in any kind of production environment...
<snip>
What is it about RHL that various people wouldn't
recommend running it in a production envornment?
I don't have a contrary view, so much as I'd like to
know what's specifically wrong with the RH distribution.
We're trying to decide on a distribution on which to
develop telecom software, utilizing PostgreSQL of
course :-) What other distributions would you
recommend and why?
Tim
From: "Tim Barnard" <tbarnard@povn.com>
To: <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL
On 27 Jun 2001, Tim Barnard wrote:
<snip>
...This is not the same in my book, since I don't care
to run RHL in any kind of production environment...
<snip>
What is it about RHL that various people wouldn't
recommend running it in a production envornment?
I don't have a contrary view, so much as I'd like to
know what's specifically wrong with the RH distribution.
We're trying to decide on a distribution on which to
develop telecom software, utilizing PostgreSQL of
course :-) What other distributions would you
recommend and why?
Tim
On Wednesday 27 June 2001 16:43, Alex Knight wrote: > 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. Been there, done that. 7.1 is much better -- both for Red Hat and PostgreSQL... Out of the box, RHL7.1 is tight -- the firewall ruleset defaults to HIGH -- which means no connections at all are allowed in. > 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. And there's something wrong with RPM? It sure makes it easier -- at least I can't install software that is linked against the wrong libc versions. > (Yeah, sure you can spend time securing and setting up the box to not > run what it shouldn't be... _OR_ you can save that wasted time (it adds up > when you are setting up 30 production machines) and run a quality > distribution like Debian or even Slackware) When you do 30 machines, you use Kickstart and make each machine the way you want it, on a cookie-cutter-like system. You only have running what you install -- and if you don't go through and set the system up right on any distribution, you will get problems anyway. > I'm sure we could go on, but this isn't a Linux list :) No, it isn't. But statements on how RHL isn't suitable for a production PostgreSQL system will be answered. Politely, of course. Again, there are several systems you can go with -- RHL is but one of them. I have experience with it in a moderately demanding environment (mission critial broadcast applications are running on PostgreSQL here, on RHL). I would have no problem running any of the excellent Linux distributions, OpenBSD, or FreeBSD here -- as long as RealAudio runs, I'm happy. In May 1997 RedHat Linux was the only RealAudioServer-supported Open Source OS. If it ain't broke, don't fix it -- and RHL ain't broke. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Alex Knight <knight@phunc.com> 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.
On Wednesday 27 June 2001 16:45, Alex Knight wrote: > On Wed, 27 Jun 2001, Lamar Owen wrote: > > 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, > 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. My server has hit an Apache Bench level, with 100 simultaneous connections, using an OpenACS test page, of 15 pages per second -- which doesn't sound like much until you find out that the page in question involved no less than _six_ PostgreSQL queries. And it saturated the 10Mbps ethernet segment it was on during the test. And this was with RHL 5.2. I haven't benched 7.1 as yet. While doing live audio encoding to multiple streams. Tell me this -- if Red Hat is using the same kernel as Debian, how can Debian do a better job on performance, all daemons being equal? Same compiler -- same kernel -- same processor -- different packagers. Why would Debian be better in that circumstance? > I have a T1 to my house, and I saturate it all the time... without load :) Saturating a T1 on download doesn't count. :-) No, I don't have a system that would load down one of Above.Net's OC12's (and their larger pipes....). But I do have solid 24x7 experience running a solid Red Hat system -- and, for my production purposes it runs just fine. Better than fine, actually. And PostgreSQL is a big part of that -- even if we don't load things as heavy as some, it still works. Reliably. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
My last two cents on the issue. We should really drop it now, AFAIK, I have no reason to bash RedHat, nor defend any other OS's. People make their own decisions. I'll be happy to take this offline if someone wishes to further discuss the pros and cons of any Linux distribution. > > 3) So much extra crap running to begin with, eating up extra memory, cpu, > > etc. (Yeah, sure you can spend time securing and setting up the box to not > > run what it shouldn't be... _OR_ you can save that wasted time (it adds up > > when you are setting up 30 production machines) and run a quality > > distribution like Debian or even Slackware) > > I'm just sticking these together because they are really the same issue, > and an administrative one, not engineering. > > You can set up your machines however you wish. While I generally prefer > Debian for standalone systems because dselect makes it easy to add and remove > things without spending a lot of time looking for other files, I've found that > recent Red Hat is very manageable, especially if you are building a custom > installation or your own .rpm files. > > It all boils down to how much time you want to spend dealing with your > installation and how custom you want it. For a moderate fee, I'll build you a > Red Hat kickstart CD that includes exactly what you want and doesn't start so > much stuff "out of the box". For a lesser fee I'll tell you how. For free, > you can learn. Yes, the default install puts a lot of crap most people don't > want on the system. Defaults are typically not production settings. Bravo. That's all very true. As for the last statement about defaults... Ofcourse. You always have to tune a machine for production use, however, things like having to disable "lpd" are certainly wasted time. Or "portmapper"... Jesus... That shouldn't be running unless you _need_ it. If you _really_ want, you can setup a Debian footprint system that only takes up 50mb... Let's see a RedHat installation do that. > > > 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. > > So? So? I'd consider using RedHat again if a few things were changed... One of which was that I _didn't_ have to use RPMs. When a software vendor creates RPMs only, it's rather disturbing. Apparently, from my own observations, I've noticed that commercial vendors who write software for RedHat, tend to only release RPM packages, where as vendors who write for any other distro or Linux in general, tend to use something more universal (tar for example). > [Note: this is going to be my only comment on the subject of distributions, since > it is even further away from the scope of this list then the support of > PostgreSQL by Red Hat] I'm done.
On Wednesday 27 June 2001 16:51, Bruce Momjian wrote: > I don't think it is healthy to suggest that RH will be releasing their > own custom modifications to the PostgreSQL core server, unless you know > something we don't. :-) If I did know such, I couldn't tell anybody ;-). My intent wasn't to suggest what, on a third reading, my message seems to imply. Thank you for catching that for me, Bruce. > All indications I have heard are that they will be submitting patches > just like everyone else, and will be working on admin tools too. Maybe > that is what you were referring to about a separate license. That is what I meant, of course -- I just didn't phrase it well. Patches can be released with a different license than the code they're patching. However, I would be surprized if their shipped RHDB product didn't incorporate changes that they came up with -- even if the PostgreSQL group didn't apply them to the base dist. Although I certainly reserve the right to be wrong. Yes, I know that may not be healthy. Yet they do it now with the Linux kernel (their 'enterprise' kernel patches, for instance) -- why would PostgreSQL be any different? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On 27 Jun 2001, Trond Eivind Glomsrød wrote: > Alex Knight <knight@phunc.com> 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. Trond, Show me unbiased third-party data. -Knight
On Wed, Jun 27, 2001 at 05:03:33PM -0400, Lamar Owen wrote: : I think most people that say they'd not run RHL either simply don't like : Linux or just don't like Red Hat. Nothing different in this than the : attitude of MySQL users who just simply don't like PostgreSQL. Or they've : heard that Postgres95 1.01 was a dog, so they won't use PostgreSQL 7.1.2. : The same comparison holds for Red Hat -- the number of possible reasons to : not use it in a production, 24x7, high-load environment are shrinking with : every release. Well, to defend some of those people, we're writing a very database intensive app that's attempting to be SQL agnostic. For the most part it works with MySQL and Postgres both (one or two minor hacks in the database abstraction layer to support features that are just *too* different to code around). When we run this system under Solaris x86, MySQL kicks the pants off Postgres using the same data. When we switched that over to an identical box running Linux (it's RH7.1, but really, it's the kernel and underlying system that matter), Postgres runs much better than both the Solaris MySQL and Postgres installs with the same data and code. I had almost given up on using Postgres for this system because under Solaris, it just couldn't cut it (MySQL could do the work with one CPU while Postgres took up even more CPU and required *both* CPUs to be enabled), but when we moved the system to a Linux box, things worked much better. Go figure. I'm sure that many people's attitudes about RH are the same way. Older versions of RedHat just felt really bloated and slow. RH7.1 feels much tighter, but if I had been turned off by older versions, I never would've tried it. * Philip Molter * DataFoundry.net * http://www.datafoundry.net/ * philip@datafoundry.net
> On Wed, Jun 27, 2001 at 01:04:27PM -0700, some SMTP stream spewed forth: > > <snip> > > ...This is not the same in my book, since I don't care > > to run RHL in any kind of production environment... > > <snip> > > > > What is it about RHL that various people wouldn't > > recommend running it in a production envornment? > > I don't have a contrary view, so much as I'd like to > > know what's specifically wrong with the RH distribution. > > We're trying to decide on a distribution on which to > > develop telecom software, utilizing PostgreSQL of > > course :-) What other distributions would you > > recommend and why? > > None of them. Run FreeBSD. It's better. > Redhat (and, well, Linux) is mostly geared toward Desktops. > It is supposedly "userfriendly", which just makes it a piece of crap and > buggy. If you prefer using things like "RPM" and dealing with GNU > crappage and glibc issues all the time, then you probably want to use > Linux., possibly in the form of Redhat if you really feel sadistic. Being a hardcore FreeBSD follower, I agree FreeBSD is great for server scenarios. But, Linux can be a great server too, especially with the 2.4.x kernel releases; iptables > *. Too bad the poor people at RH couldn't keep up. ;) *poke poke* Knight
> > 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. I have. Maybe you need a refresher? ;) > > > > 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. Obviously. Considering I've been using RedHat (still do in non-production environments) since it came out, and Linux since the beginning of 1993, I'm certainly very familiar with it. If you are telling me that a default install does _not_ have a bunch of needless things running for production environments, you're probably the one not experienced running enterprise level servers in a production environment with RedHat. Just because you work there doesn't make you an expert. In the field, we tend to have more experience than the guy who sits behind the desk writing drivers, or answering phone calls in a NOC. > > 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. I'm sorry you feel that way. I can understand your approach though, considering the big bad wolf just came in and tore apart your sweet little daughter. -Knight
> 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". ; ) steve
On Wednesday 27 June 2001 17:17, Bruce Momjian wrote: > > However, I would be surprized if their shipped RHDB product didn't > > incorporate changes that they came up with -- even if the PostgreSQL > > group didn't apply them to the base dist. Although I certainly reserve > > the right to be wrong. Yes, I know that may not be healthy. Yet they do > > it now with the Linux kernel (their 'enterprise' kernel patches, for > > instance) -- why would PostgreSQL be any different? > That would concern me if it ever happened. GB hasn't done it and I hope > RH doesn't either. But they certainly are within license rights to do so. However, knowing the 'Red Hat Way' as I do :-), the enhancements are almost always packaged as patches, not as a modified tarball. That is the RPM packager's credo -- Pristine Source. Patch all you want to -- just leave the source tarball alone. The kernel RPMset that is installed has literally hundreds of patches being applied -- to the pristine kernel.org tarball. I see no indication that this would change at all. Debian is doing the same with the PostgreSQL patches -- see the 'peer' authentication discussion in HACKERS (that dropped out after I posted a link to the patchset....). Debian is, right now, distributing a fairly modified PostgreSQL package -- 'peer' authentication, after all, is NOT standard fare. This is one good side effect of their calling it 'Red Hat Database' -- their users aren't as likely to run to postgresql.org for support :->. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > 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. Well, Microsoft has an even greater installed base in enterprise deployments, so NT must be better than Linux.... Being #1 doesn't make you the best. steve
As long as it's a robust, managable, and open arhcitecture, I'm generally agnostic as to technoliogies. That said, my red hat experience: ran multiple java application servers and multiple oracle 8i db instances on red hat 6.n (medium size 100-200 tables) with a moderately high computationally and datbase intensive application. consistently ran 6 9's uptime (what little downtime there was generally due to pilot error or buggy code) these servers served from 10-to-25 thousand users daily. we ran many months 100% uptime. tjm -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Alex Knight Sent: Wednesday, June 27, 2001 1:46 PM To: Lamar Owen Cc: Vivek Khera; pgsql-general@postgresql.org Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL 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. I have a T1 to my house, and I saturate it all the time... without load :) -Knight ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> > 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. I consider things like the portmapper being enabled by default Red Hat specific. > > 3) So much extra crap running to begin with, eating up extra memory, cpu, > > etc. > > You're obviously unfamiliar with it. I don't know, I generaly turn off at least half of the services that are enabled by default, which free up quite a bit of memory. steve
> > 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? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Ok, I was lying. RedHat > * On Wed, 27 Jun 2001, Tim Barnard wrote: > Wow, I didn't realize I was going to open such a big can of worms :-) > > Thanks to everyone for putting in their "two-cents worth." > All of the responses have definitely been helpful. And I > agree with Adam, et al, this really doesn't belong on this > list so lets end this thread and move on. > > Thanks again. > > Tim > > ----- Original Message ----- > From: "Tim Barnard" <tbarnard@povn.com> > To: <pgsql-general@postgresql.org> > Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL > > On 27 Jun 2001, Tim Barnard wrote: > > <snip> > ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... > <snip> > > What is it about RHL that various people wouldn't > recommend running it in a production envornment? > I don't have a contrary view, so much as I'd like to > know what's specifically wrong with the RH distribution. > We're trying to decide on a distribution on which to > develop telecom software, utilizing PostgreSQL of > course :-) What other distributions would you > recommend and why? > > Tim > > >
> I had almost given up on using Postgres for this system because under > Solaris, it just couldn't cut it (MySQL could do the work with one CPU > while Postgres took up even more CPU and required *both* CPUs to be > enabled), but when we moved the system to a Linux box, things worked > much better. Ah, back to a PostgreSQL topic. :-) My guess on this one is that Solaris is slower for PostgreSQL because process switching is _much_ heavier on Solaris than other OS's. This is because of the way they implemented processes in SVr4. They got quite heavy, almost requiring kernel threads so you weren't switching processes all the time. In a sense threads were a solution to a process bloating problem. Linux/BSD have much lighter processes and hence work better for PostgreSQL. Again, this is only a guess. MySQL does more stuff with threads while PostgreSQL switches process because each backend is a process. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> 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.
> None of them. Run FreeBSD. It's better. Or, it will be, once the SMP code is improved. : ) steve
> > On Wed, Jun 27, 2001 at 01:04:27PM -0700, some SMTP stream spewed forth: > > > <snip> > > > ...This is not the same in my book, since I don't care > > > to run RHL in any kind of production environment... > > > <snip> > > > > > > What is it about RHL that various people wouldn't > > > recommend running it in a production envornment? > > > I don't have a contrary view, so much as I'd like to > > > know what's specifically wrong with the RH distribution. > > > We're trying to decide on a distribution on which to > > > develop telecom software, utilizing PostgreSQL of > > > course :-) What other distributions would you > > > recommend and why? > > > > None of them. Run FreeBSD. It's better. > > Redhat (and, well, Linux) is mostly geared toward Desktops. > > It is supposedly "userfriendly", which just makes it a piece of crap and > > buggy. If you prefer using things like "RPM" and dealing with GNU > > crappage and glibc issues all the time, then you probably want to use > > Linux., possibly in the form of Redhat if you really feel sadistic. > > Being a hardcore FreeBSD follower, I agree FreeBSD is great for server > scenarios. But, Linux can be a great server too, especially with the 2.4.x > kernel releases; iptables > *. > > Too bad the poor people at RH couldn't keep up. ;) *poke poke* > > Knight Joke removed. -Knight
To all who are fanning the flames -- this is not the place for prolonged discussion on operating systems (nor sarcasm and zealous diatribes), is it? -- please take it offline (please?) thanks in advance tjm "Imensis laboribus comparatur emditio: ac post moriendum est." -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Bruce Momjian Sent: Wednesday, June 27, 2001 3:28 PM To: Trond Eivind Glomsrod Cc: Alex Knight; Lamar Owen; Vivek Khera; pgsql-general@postgresql.org Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL > > 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? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
> > 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". ; ) > > steve Yep.
* Bruce Momjian <pgman@candle.pha.pa.us> wrote: | > the Linux kernel (their 'enterprise' kernel patches, for instance) -- why | > would PostgreSQL be any different? | | That would concern me if it ever happened. GB hasn't done it and I hope | RH doesn't either. | I think this is a good thing - it just illustrates that open source works. For instance, there are threading patches for the linux kernel that significantly increase the performance of multithreaded Java applications - but last time I checked Linus hadn't bother to put them into his release of the kernel. That doesn't prevent me from using them and that makes me all the happier... But I think something like this only would happen when one cannot reach consensus on design or requirements. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
"Steve Wolfe" <steve@iboats.com> 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.
> Bruce Momjian <pgman@candle.pha.pa.us> 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. You make a good point Trond. It certainly does power _some_ of the sites, and it certainly suites more than a few happy people. -Knight
> You can set up your machines however you wish. While I > generally prefer Debian for standalone systems because > dselect makes it easy to add and remove things without spending > a lot of time looking for other files, I've found that recent > Red Hat is very manageable, especially if you are building a > custom installation or your own .rpm files. Speaking of Debian, seems they are the first vendor to ship an "enhanced" PostgreSQL distribution. Didn't someone report a new pg_hba.conf option on Debian called "peer" recently. We don't have such an option and it was never submitted to us a a patch. I don't remember what it does. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > > 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? Absolutely. -Knight
On Wed, 27 Jun 2001, Steve Wolfe wrote: > > > 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. > > I consider things like the portmapper being enabled by default Red Hat > specific. > > > > 3) So much extra crap running to begin with, eating up extra memory, > cpu, > > > etc. > > > > You're obviously unfamiliar with it. > > I don't know, I generaly turn off at least half of the services that are > enabled by default, which free up quite a bit of memory. > > steve Yup, which is my point. On a 30 server deployment, and tight schedules, deploying Debian is much smoother, cleaner, more secure, and less "after install" configuration to do. It's like cooking a 3 course meal... then having to _bake a cake_ for desert. -Knight
On 28 Jun 2001, Gunnar Rønning wrote: > * Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > | > the Linux kernel (their 'enterprise' kernel patches, for instance) -- why > | > would PostgreSQL be any different? > | > | That would concern me if it ever happened. GB hasn't done it and I hope > | RH doesn't either. > | > > I think this is a good thing - it just illustrates that open source works. > For instance, there are threading patches for the linux kernel that > significantly increase the performance of multithreaded Java applications - but > last time I checked Linus hadn't bother to put them into his release of the > kernel. That doesn't prevent me from using them and that makes me all the > happier... > > But I think something like this only would happen when one cannot reach > consensus on design or requirements. I agree. I highly embrace the fact that RedHat may find PostgreSQL attractive enough to put their energies, development teams, and general financing. It has been proven to aid both, the development company and the open source project, when a company decides to embrace an open-source project. Knight
On Wed, 27 Jun 2001, Steve Wolfe wrote: > > None of them. Run FreeBSD. It's better. > > Or, it will be, once the SMP code is improved. : ) > > steve I vote that we all dump what we have, and run Windows 3.11. -Knight
Alex Knight wrote:
>
> > > > 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?
>
> Absolutely.
>
Let me think about this.... Ahhhhh nope...;-)
It could mean that MS has marketed there wares more strategically than
any other product, paying for positive advertisement helps you quite a
bit in the sales category...;-)
But hey, that's your freedom to think, act, speak, and decide.
--
/) John Clark Naldoza y Lopez (\
/ ) Software Design Engineer II ( \
_( (_ _ Web-Application Development _) )_
(((\ \> /_> Cable Modem Network Management System <_\ </ /)))
(\\\\ \_/ / NEC Telecom Software Phils., Inc. \ \_/ ////)
\ / \ /
\ _/ phone: (+63 32) 233-9142 loc. 3112 \_ /
/ / cellphone: (+63 919) 399-4742 \ \
/ / email: njclark@ntsp.nec.co.jp \ \
Alex Knight wrote: > > On Wed, 27 Jun 2001, Steve Wolfe wrote: > > > > > 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. > > > > I consider things like the portmapper being enabled by default Red Hat > > specific. > > > > > > 3) So much extra crap running to begin with, eating up extra memory, > > cpu, > > > > etc. > > > > > > You're obviously unfamiliar with it. > > > > I don't know, I generaly turn off at least half of the services that are > > enabled by default, which free up quite a bit of memory. > > > > steve > > Yup, which is my point. On a 30 server deployment, and tight schedules, > deploying Debian is much smoother, cleaner, more secure, and less "after > install" configuration to do. > > It's like cooking a 3 course meal... then having to _bake a cake_ for > desert. > Has anyone tried using Trustix (http://www.trustix.net/)??? It's based upon RH 6.2...;-) -- /) John Clark Naldoza y Lopez (\ / ) Software Design Engineer II ( \ _( (_ _ Web-Application Development _) )_ (((\ \> /_> Cable Modem Network Management System <_\ </ /))) (\\\\ \_/ / NEC Telecom Software Phils., Inc. \ \_/ ////) \ / \ / \ _/ phone: (+63 32) 233-9142 loc. 3112 \_ / / / cellphone: (+63 919) 399-4742 \ \ / / email: njclark@ntsp.nec.co.jp \ \
On Wed, Jun 27, 2001 at 06:58:18PM -0400, Bruce Momjian wrote: : My guess on this one is that Solaris is slower for PostgreSQL because : process switching is _much_ heavier on Solaris than other OS's. This is : because of the way they implemented processes in SVr4. They got quite : heavy, almost requiring kernel threads so you weren't switching : processes all the time. : : In a sense threads were a solution to a process bloating problem. : Linux/BSD have much lighter processes and hence work better for : PostgreSQL. Again, this is only a guess. : : MySQL does more stuff with threads while PostgreSQL switches process : because each backend is a process. Does more stuff with threads? It does all stuff with threads. Your guess was our guess, which is why we tried shoving the thing over to a Linux box. Now if I only I could figure out why kernel CPU usage keeps going up incrementally over time (went from roughly a 5% average to a 16% average in two days) the more we run the system. All signs are pointing to postgres. VACUUM ANALYZE-ing the tables used to reduce it back down, but now, it doesn't appear to be as effective (might go from 16% back down to 13%). Anyone know what causes that, and better yet, anyone know how to fix it? We see similar behavior under Solaris. * Philip Molter * DataFoundry.net * http://www.datafoundry.net/ * philip@datafoundry.net
> : In a sense threads were a solution to a process bloating problem. > : Linux/BSD have much lighter processes and hence work better for > : PostgreSQL. Again, this is only a guess. > : > : MySQL does more stuff with threads while PostgreSQL switches process > : because each backend is a process. > > Does more stuff with threads? It does all stuff with threads. Your > guess was our guess, which is why we tried shoving the thing over to a > Linux box. Now if I only I could figure out why kernel CPU usage keeps > going up incrementally over time (went from roughly a 5% average to a > 16% average in two days) the more we run the system. All signs are > pointing to postgres. > > VACUUM ANALYZE-ing the tables used to reduce it back down, but now, it > doesn't appear to be as effective (might go from 16% back down to > 13%). Anyone know what causes that, and better yet, anyone know how to > fix it? We see similar behavior under Solaris. My only guess is index growth. We don't reclaim disk space used by indexes after data removal. You have to drop/recreate the index. It is on the TODO list. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
At 07:00 PM 27-06-2001 -0400, Trond Eivind Glomsrød wrote: >"Steve Wolfe" <steve@iboats.com> 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. Why openssh, portmap and sendmail? I'm not familiar with RH7 and later, but the older redhat's distros had way too much on by default. I have to keep turning off inetd. Still I use RH coz I can't be bothered to keep tweaking my kernel for development servers (I still tweak for the firewall). The max process/users and other similar default settings from www.linux.org just don't cut it. Cheerio, Link.
I forgot to mention this in the last email. For the record, we are updating the book daily, and the changes we make are on the website daily. In other words, as we receive feedback you will see changes occuring. So please keep the feedback coming, good and bad. Again the book is at: http://www.opendocspublishing.com/comments.lxp?lxpe=92 Thanks for all the feedback, it really helps.
> ...This is not the same in my book, since I don't care > to run RHL in any kind of production environment... No idea what you're talking about. I've been running RH 24/7 in various places for various tasks, including routers, and production servers, and I've never had a problem. I've been running it since RH 5.0. Stability is not an issue, because it's Linux. Security is also not an issue if you configure your system properly and follow and read security and other advisories from the RH site and other security related sites. RH are usually reasonably good with keeping reasonably up to date with patches and updates. Please, tell us all of your experiences to the contrary. Were they caused by slapping on a default installation and hoping that it would "just work"? If you have a good argument, then I certainly don't want to run an inferior distribution - I accept that the fact that I haven't discovered the shortcomings over the last few years doesn't mean that they are not there... Regards. Gordan
> 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. That proves absolutely nothing. Any sysop that installs a standard installation and hopes for the best is a fool. If you are running a production server, you will first apply all the latest patches, and switch off all the services that are not used. That will usually be a good starting point, and it only takes minutes to do. It's damn easy to say that an OS like OpenBSD is "most secure" if no services are running by default. It's almost like taking a server, switching it off, unplugging it from everything, putting it in a steel barrel, pouring concrete over it, and chucking it overboard over Mindanao Deep. I'd agree that that is pretty damn secure. But also pretty damn useless... > 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. What's wrong with RPM? Most software nowdays comes optionally pre-packaged using RPM. And if your distribution doesn't support RPM, then it isn't all that hard to install RPM and use that. For crying out loud, I've installed RPM on a Sun3 server that was running SunOS 4.1.1! Why? Because it made package management, installation and removal so much easier! What is the problem with RPM? Don't you know how to install it from source on a distribution that doesn't come with it? > 3) So much extra crap running to begin with, eating up extra memory, cpu, > etc. (Yeah, sure you can spend time securing and setting up the box to not > run what it shouldn't be... _OR_ you can save that wasted time (it adds up > when you are setting up 30 production machines) and run a quality > distribution like Debian or even Slackware) I am dissapointed to hear that. Surely, you STILL have to go through the startup scripts and determine what you are running, on any distribution. On RH, I use "setup", and I can have the services switched off or on as required in about 6 seconds. 30 systems x 6 seconds = 3 minutes. I think I can live with that. > I'm sure we could go on, but this isn't a Linux list :) You're right. We should stop, or at least take this off the list. Regards. Gordan
> 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' :-). What are you referring to when you say "firewall"? portsentry? ipchains total lockdown setup? > The 2.4 Linux kernel is a big win for me -- I saw a factor > of two performance increase on the regression suite when I upgraded to kernel > 2.4 over 2.2 on the same hardware -- it's nice for the parallel tests to run > in 44 seconds on our PIII 600. Not a screamer -- but not a slouch. Can you please explain what you mean here? Was it just a straight kernel upgrade? Where does the performance increase come from? I'm still running 2.2 and I an trying to hold off upgrading for a while just to make sure that 2.4 goes through a few revisions and fixes. In particular, what runs so much faster with 2.4? Cheers. Gordan
Lamar Owen <lamar.owen@wgcr.org> wrote: > Tell me this -- if Red Hat is using the same kernel as Debian, Technically speaking, this is a false premise. Just about every distributions ships with kernels that are modified to some degree (e.g. extra drivers, backported drivers). I know Red Hat does; I know Debian does as well. > how can Debian do a better job on performance, all daemons being equal? Theoretically speaking, for instance by careful optimisation (e.g. processor-variant-specific builds of libraries and daemons). > Same compiler Not always, remember http://gcc.gnu.org/gcc-2.96.html? (An unfortunate incident I admit; I certainly appreciate Cygnus / Red Hat's significant contributions to the development of gcc, glibc and binutils) > -- same kernel -- same processor -- different packagers. Why would Debian > be better in that circumstance? I don't expect significant performance differences between Red Hat and Debian either way. The differences that exist are primarily the result of different development models, Red Hat's one being one with a fairly small central core maintained by employees of a company and augmented by a large collection of contributed packages of varying quality, and Debian's one of a large set of packages maintained by a large group of volunteers and held together through an explicit policy (http://www.debian.org/doc/debian-policy/) with virtually no externally contributed packages. Ray -- AJ: Geeez, Erwin. He wasn't even ARMED. Erwin: I don't care. I have lots of ammo and he was wearing a TIE. http://ars.userfriendly.org/cartoons/?id=20010209
> > > 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. > > Well, Microsoft has an even greater installed base in enterprise > deployments, so NT must be better than Linux.... > > Being #1 doesn't make you the best. You've hit a nail on the head there. However, FORTUNATELY, RH base their products on something that's stable to begin with, so as long as they stick with the strategy of using clean source and do everything else with patches, I think the amount they can go wrong by is fairly seriously limited. Regards. Gordan
On Wed, 27 Jun 2001, Bruce Momjian wrote:
> pg_hba.conf option on Debian called "peer" recently. We don't have such
> an option and it was never submitted to us a a patch.
From 7usr/share/doc/postgresql/README.Debian.gz:
6. Unix socket authentication is provided (authentication type "peer").
This works just like ident, but for Unix sockets; this provides a more
secure method of authentication than ident, and does not require
administrators to run identd on their servers. This authentication
method has been submitted to the upstream developers, but is not
currently part of the upstream release.
I don´t know if the Debian maintainer has it submitted but I trust him
if he writes it in the relevant document.
Kind regards
Andreas.
> > 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. Excuse me? When did that happen? What year is it? Regards. Gordan
Folks,
I'm really sorry to disturb you party. Seems yall have a lot
of fun. But can't you guy's ask Mark for a pgsql-oto list?
It's not that I'm unable to ignore a thread by subject at
some stage. But some people are distracted from pgsql mailing
lists because of their traffic even without those off topic
blasts.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
So does this impact Postgresql's performance on Windows as well? I think Apache
had to rewrite their Windows port to use threads instead of processes before
they got decent performance on that platform. Any chance of Postgresql doing
that sort of thing? Not that I'm asking for the change; I'd just as soon use
this as one more reason to keep running it on linux. :-)
--Wes
Bruce Momjian <pgman%candle.pha.pa.us@interlock.lexmark.com> on 06/27/2001
06:58:18 PM
To: Philip Molter <philip%datafoundry.net@interlock.lexmark.com>
cc: Lamar Owen <lamar.owen%wgcr.org@interlock.lexmark.com>, Tim Barnard
<tbarnard%povn.com@interlock.lexmark.com>,
pgsql-general%postgresql.org@interlock.lexmark.com (bcc: Wesley
Sheldahl/Lex/Lexmark)
Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL
> I had almost given up on using Postgres for this system because under
> Solaris, it just couldn't cut it (MySQL could do the work with one CPU
> while Postgres took up even more CPU and required *both* CPUs to be
> enabled), but when we moved the system to a Linux box, things worked
> much better.
Ah, back to a PostgreSQL topic. :-)
My guess on this one is that Solaris is slower for PostgreSQL because
process switching is _much_ heavier on Solaris than other OS's. This is
because of the way they implemented processes in SVr4. They got quite
heavy, almost requiring kernel threads so you weren't switching
processes all the time.
In a sense threads were a solution to a process bloating problem.
Linux/BSD have much lighter processes and hence work better for
PostgreSQL. Again, this is only a guess.
MySQL does more stuff with threads while PostgreSQL switches process
because each backend is a process.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
On Wed, 27 Jun 2001, Philip Molter wrote: > On Wed, Jun 27, 2001 at 06:58:18PM -0400, Bruce Momjian wrote: > : My guess on this one is that Solaris is slower for PostgreSQL because > : process switching is _much_ heavier on Solaris than other OS's. This is > : because of the way they implemented processes in SVr4. They got quite > : heavy, almost requiring kernel threads so you weren't switching > : processes all the time. > : > : In a sense threads were a solution to a process bloating problem. > : Linux/BSD have much lighter processes and hence work better for > : PostgreSQL. Again, this is only a guess. > : > : MySQL does more stuff with threads while PostgreSQL switches process > : because each backend is a process. > > Does more stuff with threads? It does all stuff with threads. Your > guess was our guess, which is why we tried shoving the thing over to a > Linux box. Now if I only I could figure out why kernel CPU usage keeps > going up incrementally over time (went from roughly a 5% average to a > 16% average in two days) the more we run the system. All signs are > pointing to postgres. Or Linux. Try 2.4 kernel which is far better as far as SMP goes. Regarding threads, there's a very good quote from Linus: "Solution to slow process switching is fast process switching, not another kernel abstraction". > VACUUM ANALYZE-ing the tables used to reduce it back down, but now, it > doesn't appear to be as effective (might go from 16% back down to > 13%). Anyone know what causes that, and better yet, anyone know how to > fix it? We see similar behavior under Solaris. Look at linux profiling tools. -alex
On Wednesday 27 June 2001 18:58, Bruce Momjian wrote: > > I had almost given up on using Postgres for this system because under > > Solaris, it just couldn't cut it (MySQL could do the work with one CPU > > while Postgres took up even more CPU and required *both* CPUs to be > > enabled), but when we moved the system to a Linux box, things worked > > much better. > Ah, back to a PostgreSQL topic. :-) > My guess on this one is that Solaris is slower for PostgreSQL because > process switching is _much_ heavier on Solaris than other OS's. This is > because of the way they implemented processes in SVr4. They got quite > heavy, almost requiring kernel threads so you weren't switching > processes all the time. Now, the question of the week: Is supporting a thread model for an inefficient OS a desirable thing to do, when more efficient OS kernels are available such as FreeBSD 4.x and Linux 2.4? My opinion is that our existing model, when used with a connection-pooling frontend, is rather efficient. (Yes, I use a connection-pooling frontend. Performance is rather nice, and I don't have to have a full backend spawned for every page hit.) In fact, on a Linux box threads show as processes. While I know that the kernel actually supports themin a slightly different manner than processes, they have more similarities than differences. However, even on OS's where threads are supported, the mechanism to support those threads must be an efficient one -- not all pthreads libraries are created equal. Many are frontends (expensive ones, at that) for plain old processes. Does anyone know of a resource that details the 'weight' of processes for our supported platforms? [reply off-list -- I'll be glad to summarize responses to HACKERS, ADMIN, or PORTS, as appropriate, if desired.] -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Thu, Jun 28, 2001 at 11:22:00AM -0400, Alex Pilosov wrote: : Possible. How many concurrent connections you have? How many postgresql : processes you have running? We have anywhere from 10-50 processes concurrently using the database at any given time. One process is running a join with about 9 tables in it approximately once every 1-2 seconds. The other processes are updating data into three tables. It's definitely related to indexing (and I think someone else posted that the index space doesn't get freed, which could result in more work for the OS and that it was on the TODO list). I just dropped and recreated the indices on the most problematic of the tables (the one that has just recently been taking 1-2 minutes to vacuum) and kernel CPU usage went from about 17-20% to 4%. * Philip Molter * DataFoundry.net * http://www.datafoundry.net/ * philip@datafoundry.net
On Thu, Jun 28, 2001 at 10:45:30AM -0400, Alex Pilosov wrote: : On Wed, 27 Jun 2001, Philip Molter wrote: : : > On Wed, Jun 27, 2001 at 06:58:18PM -0400, Bruce Momjian wrote: : > : My guess on this one is that Solaris is slower for PostgreSQL because : > : process switching is _much_ heavier on Solaris than other OS's. This is : > : because of the way they implemented processes in SVr4. They got quite : > : heavy, almost requiring kernel threads so you weren't switching : > : processes all the time. : > : : > : In a sense threads were a solution to a process bloating problem. : > : Linux/BSD have much lighter processes and hence work better for : > : PostgreSQL. Again, this is only a guess. : > : : > : MySQL does more stuff with threads while PostgreSQL switches process : > : because each backend is a process. : > : > Does more stuff with threads? It does all stuff with threads. Your : > guess was our guess, which is why we tried shoving the thing over to a : > Linux box. Now if I only I could figure out why kernel CPU usage keeps : > going up incrementally over time (went from roughly a 5% average to a : > 16% average in two days) the more we run the system. All signs are : > pointing to postgres. : : Or Linux. Try 2.4 kernel which is far better as far as SMP goes. We are running a 2.4 kernel. All signs point to Postgres because it's happening under both Linux and Solaris (although the effect is much more pronounced under Solaris). : Look at linux profiling tools. I can profile all day long but when I see the same behavior under two different operating systems caused by the same database, I naturally gravitate towards the database being the problem, not the OS. * Philip Molter * DataFoundry.net * http://www.datafoundry.net/ * philip@datafoundry.net
>> I had almost given up on using Postgres for this system because under
>> Solaris, it just couldn't cut it (MySQL could do the work with one CPU
>> while Postgres took up even more CPU and required *both* CPUs to be
>> enabled), but when we moved the system to a Linux box, things worked
>> much better.
> Ah, back to a PostgreSQL topic. :-)
> My guess on this one is that Solaris is slower for PostgreSQL because
> process switching is _much_ heavier on Solaris than other OS's.
If this is 7.1, another fairly likely possibility is that the fsync
method being used for the WAL log needs to be changed on the Solaris
box. The reason we have so many options is that some methods are way
slower than others on certain platforms --- but we don't yet have
anything in there to pick the right method for a given platform.
Could you experiment with WAL_SYNC_METHOD on the Solaris system
and see if your results change?
regards, tom lane
> > > So does this impact Postgresql's performance on Windows as well? I think Apache > had to rewrite their Windows port to use threads instead of processes before > they got decent performance on that platform. Any chance of Postgresql doing > that sort of thing? Not that I'm asking for the change; I'd just as soon use > this as one more reason to keep running it on linux. :-) Again, a PostgreSQL topic... Going with threads is a major issue and not one we would do lightly. The significant issue is that we may gain on certain platforms like NT and maybe Solaris, but I am unsure about the others. We may lose on the others and it is hard to make both a threaded and non-threaded version of the backend. Yes, I know it can be done but is it worth the effort is the question. There is a TODO item with email about threads that you can review. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> On Wed, 27 Jun 2001, Bruce Momjian wrote: > > > pg_hba.conf option on Debian called "peer" recently. We don't have such > > an option and it was never submitted to us a a patch. > >From 7usr/share/doc/postgresql/README.Debian.gz: > 6. Unix socket authentication is provided (authentication type "peer"). > This works just like ident, but for Unix sockets; this provides a more > secure method of authentication than ident, and does not require > administrators to run identd on their servers. This authentication > method has been submitted to the upstream developers, but is not > currently part of the upstream release. > > I don?t know if the Debian maintainer has it submitted but I trust him > if he writes it in the relevant document. Again, PostgreSQL topic... Hmm, that is interesting. My guess is that we couldn't accept it because most OS's can't do authentication on Unix-domain sockets. It must have been long ago because I don't remember it. Peer is a nice feature, though, and it would be nice if we could support it everywhere. I don't like our 'trust' method. Too open. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 28 Jun 2001, Philip Molter wrote: > : Or Linux. Try 2.4 kernel which is far better as far as SMP goes. > > We are running a 2.4 kernel. All signs point to Postgres because it's > happening under both Linux and Solaris (although the effect is much > more pronounced under Solaris). > > : Look at linux profiling tools. > > I can profile all day long but when I see the same behavior under two > different operating systems caused by the same database, I naturally > gravitate towards the database being the problem, not the OS. Possible. How many concurrent connections you have? How many postgresql processes you have running? -alex
On Thu, 28 Jun 2001, Bruce Momjian wrote: > > On Wed, 27 Jun 2001, Bruce Momjian wrote: > > > > > pg_hba.conf option on Debian called "peer" recently. We don't have such > > > an option and it was never submitted to us a a patch. > > >From 7usr/share/doc/postgresql/README.Debian.gz: > > 6. Unix socket authentication is provided (authentication type "peer"). > > This works just like ident, but for Unix sockets; this provides a more > > secure method of authentication than ident, and does not require > > administrators to run identd on their servers. This authentication > > method has been submitted to the upstream developers, but is not > > currently part of the upstream release. > > > > I don?t know if the Debian maintainer has it submitted but I trust him > > if he writes it in the relevant document. > > Again, PostgreSQL topic... > > Hmm, that is interesting. My guess is that we couldn't accept it > because most OS's can't do authentication on Unix-domain sockets. It > must have been long ago because I don't remember it. Peer is a nice > feature, though, and it would be nice if we could support it everywhere. > I don't like our 'trust' method. Too open. True. Only linux 2.2+ supports that. I think Solaris supports that too. FreeBSD 4.3 does not support that. See following for more info: http://cr.yp.to/docs/secureipc.html http://www.superscript.com/ucspi-ipc/intro.html
>>>>> "TB" == Tim Barnard <tbarnard@povn.com> writes: TB> <snip> TB> ...This is not the same in my book, since I don't care TB> to run RHL in any kind of production environment... TB> <snip> TB> What is it about RHL that various people wouldn't TB> recommend running it in a production envornment? [ ... ] TB> course :-) What other distributions would you TB> recommend and why? It sounds like you assume one should use Linux in the first place. Basically, it all comes down to your requirements. I'm not in any way intending to start a holy war on OS preferences, but for *my* needs, Linux is not sufficient. Choose your OS to run your apps and meet your experience. If you don't have experience with any suitable OS, then go with one for which you can readily get support (either paid or from friends, associates, etc.) If neither of these apply, the roll a 20-sided die and make your selection that way. Personally, I use FreeBSD because it works the way I like, is incredibly stable, and upgrades the way I like (no version number soup). I've also used other OSes for other reasons, but these days I'm the boss so I decide. ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
>>>>> "GB" == Gordan Bobic <gordan@freeuk.com> writes: >> ...This is not the same in my book, since I don't care >> to run RHL in any kind of production environment... GB> "just work"? If you have a good argument, then I certainly don't want GB> to run an inferior distribution - I accept that the fact that I GB> haven't discovered the shortcomings over the last few years doesn't You assume I intend to run Linux at all... This is not the case. But that is *my* decision based on many years of system administration at both large and small sites. My decision obviously is not the same as yours, nor should it be unless you have my same experiences. Since *my* decision is not to run RHL (or any L) in production, the fact that RedHat supports PostgreSQL on RHL is of little consequence to me, and is not the same as RedHat offering commercial support for PostgreSQL. They are not offering such support as far as I can read. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
On Thu, Jun 28, 2001 at 11:10:04AM -0400, Tom Lane wrote: : If this is 7.1, another fairly likely possibility is that the fsync : method being used for the WAL log needs to be changed on the Solaris : box. The reason we have so many options is that some methods are way : slower than others on certain platforms --- but we don't yet have : anything in there to pick the right method for a given platform. : Could you experiment with WAL_SYNC_METHOD on the Solaris system : and see if your results change? Hrmm, well, we're running it with fsync disabled, and according to the docs, that should make the WAL_SYNC_METHOD irrelevant. We had unacceptable performance with fsync enabled. * Philip Molter * DataFoundry.net * http://www.datafoundry.net/ * philip@datafoundry.net
> Hrmm, well, we're running it with fsync disabled, and according to the > docs, that should make the WAL_SYNC_METHOD irrelevant. We had > unacceptable performance with fsync enabled. I'm not as familiar with Solaris as I am with Linux, but I do recall seeing benchmarks that show a significant speed increase in many applications (as much as 40%) by using the "best" compiler optimization flags - you may want to look at what it's being compiled with on your machine. steve
On Thursday 28 June 2001 15:33, Steve Wolfe wrote: > > Hrmm, well, we're running it with fsync disabled, and according to the > > docs, that should make the WAL_SYNC_METHOD irrelevant. We had > > unacceptable performance with fsync enabled. > I'm not as familiar with Solaris as I am with Linux, but I do recall > seeing benchmarks that show a significant speed increase in many > applications (as much as 40%) by using the "best" compiler optimization > flags - you may want to look at what it's being compiled with on your > machine. While on this subject, I just reinstalled one of our devel servers with a fresh RHL 7.1 setup, with software RAID 1 enabled (easy to do with the RHL graphical installer, FWIW). While I could have just modified the existing setup to use RAID, I wanted to dink with the partitioning as well -- which is easiest in a reinstall situation. RAID 1 doesn't change the PostgreSQL performance on the regression tests significantly. This machine, on multiple runs of 'time ./pg_regress --schedule=parallel_schedule' on the same UDMA66 drives without RAID 1 posted an average 'real' number of 44 seconds. With RAID 1 (and the same drives, controllers, OS, etc) posts an average of 42 seconds -- not statistically significant. Yes, $PGDATA was on a RAID device... :-). So, while PostgreSQL will benefit from the redundancy of the RAID, it neither suffers significantly from the write overhead, nor does it seem to greatly benefit from the increased read bandwidth, at least in the limited performance testing afforded by the regression tests (which have been used for some time as a crude benchmark). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Thu, 28 Jun 2001, Lamar Owen wrote: > On Thursday 28 June 2001 15:33, Steve Wolfe wrote: > > > Hrmm, well, we're running it with fsync disabled, and according to the > > > docs, that should make the WAL_SYNC_METHOD irrelevant. We had > > > unacceptable performance with fsync enabled. > > > I'm not as familiar with Solaris as I am with Linux, but I do recall > > seeing benchmarks that show a significant speed increase in many > > applications (as much as 40%) by using the "best" compiler optimization > > flags - you may want to look at what it's being compiled with on your > > machine. > > While on this subject, I just reinstalled one of our devel servers with a > fresh RHL 7.1 setup, with software RAID 1 enabled (easy to do with the RHL > graphical installer, FWIW). While I could have just modified the existing > setup to use RAID, I wanted to dink with the partitioning as well -- which is > easiest in a reinstall situation. > > RAID 1 doesn't change the PostgreSQL performance on the regression tests > significantly. This machine, on multiple runs of 'time ./pg_regress > --schedule=parallel_schedule' on the same UDMA66 drives without RAID 1 posted > an average 'real' number of 44 seconds. With RAID 1 (and the same drives, > controllers, OS, etc) posts an average of 42 seconds -- not statistically > significant. Yes, $PGDATA was on a RAID device... :-). > > So, while PostgreSQL will benefit from the redundancy of the RAID, it neither > suffers significantly from the write overhead, nor does it seem to greatly > benefit from the increased read bandwidth, at least in the limited > performance testing afforded by the regression tests (which have been used > for some time as a crude benchmark). Unless you are using Neil Brown's patches, you do not have increased read bandwidth. (Unless they were integrated into latest kernels). You can test it by doing time dd if=/dev/mdxx bs=64k size=(a lot) and compare it versus dd'ing from underlying device.
> RAID 1 doesn't change the PostgreSQL performance on the regression tests > significantly. This machine, on multiple runs of 'time ./pg_regress > --schedule=parallel_schedule' on the same UDMA66 drives without RAID 1 posted > an average 'real' number of 44 seconds. With RAID 1 (and the same drives, > controllers, OS, etc) posts an average of 42 seconds -- not statistically > significant. Yes, $PGDATA was on a RAID device... :-). One of the reasons is that software RAID does depend on the CPU even more than normal IDE - and when your database is being hit, the CPU is generally getting utilized pretty decently. My personal preference is to use hardware RAID 5 for redundancy, ensure that there's plenty of RAM to keep all database files in cache, and turn off fsync(). Even when our database server is maxing out all four processors, the lights on the RAID array only blink *occasionally*. : ) steve
Vivek Khera wrote: > You assume I intend to run Linux at all... This is not the case. I am sorry but I couldn't help... What do you find of your interest in this thread, then? -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
>>>>> "AB" == Alessio Bragadini <alessio@albourne.com> writes: AB> Vivek Khera wrote: >> You assume I intend to run Linux at all... This is not the case. AB> I am sorry but I couldn't help... What do you find of your interest in AB> this thread, then? The claim that "Red Hat to support PostgreSQL" appears to me a false statement. They are not supporting PostgreSQL, they are supporting their version of PostgreSQL on RHL. If you read the thread, you'd know that, since that was my original response to the original message. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Vivek, You can read the claim "Red Hat to support PostgreSQL" literally or you can infer from the statement. Yes, Red Hat's Support organization will support PostgreSQL on RH Linux. However, Red Hat has also created a development group with full-time developers to develop, advance and support the PostgreSQL product/project. Cheers, Patrick Vivek Khera wrote: > > >>>>> "AB" == Alessio Bragadini <alessio@albourne.com> writes: > > AB> Vivek Khera wrote: > >> You assume I intend to run Linux at all... This is not the case. > > AB> I am sorry but I couldn't help... What do you find of your interest in > AB> this thread, then? > > The claim that "Red Hat to support PostgreSQL" appears to me a false > statement. They are not supporting PostgreSQL, they are supporting > their version of PostgreSQL on RHL. If you read the thread, you'd > know that, since that was my original response to the original > message. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Vivek Khera, Ph.D. Khera Communications, Inc. > Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 > AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- - Patrick
Just a quicky
I think that RH's involvement will be good for all users of PostGres
whichever o/s is
run, even if you run it on Windows (!)
I'm optimistic and think that they will just muck in and help improve it
even further. MySQL has had some good marketing whereas PostGres has relied
on its technical abilities - this should make it more generally known to
the
wider world.
To me its good since there are other DB's out there they could have chosen
(MySQL has its limitations but could have been fixed, Firebird (forked
InterBase) )
I'm glad they thought PostGres was the best of the bunch and I would have
been dissapointed
if they had not.
Perhaps they will also help with non-core stuff like ODBC/ADO drivers,
admin utilities
(ala Oracle but perhaps with a few less bugs :) ), etc...
Lets give them some support and encouragement!
MC
Patrick Macdonald <patrickm@redhat.com>@postgresql.org on 05/07/2001
16:31:46
Sent by: pgsql-general-owner@postgresql.org
To: Vivek Khera <khera@kcilink.com>
cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Re: Red Hat to support PostgreSQL
Vivek,
You can read the claim "Red Hat to support PostgreSQL" literally
or you can infer from the statement. Yes, Red Hat's Support
organization will support PostgreSQL on RH Linux. However, Red
Hat has also created a development group with full-time developers
to develop, advance and support the PostgreSQL product/project.
Cheers,
Patrick
Vivek Khera wrote:
>
> >>>>> "AB" == Alessio Bragadini <alessio@albourne.com> writes:
>
> AB> Vivek Khera wrote:
> >> You assume I intend to run Linux at all... This is not the case.
>
> AB> I am sorry but I couldn't help... What do you find of your interest
in
> AB> this thread, then?
>
> The claim that "Red Hat to support PostgreSQL" appears to me a false
> statement. They are not supporting PostgreSQL, they are supporting
> their version of PostgreSQL on RHL. If you read the thread, you'd
> know that, since that was my original response to the original
> message.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D. Khera Communications, Inc.
> Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
- Patrick
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
NOTICE: The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential. If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.
Vivek Khera <khera@kcilink.com> wrote:
> The claim that "Red Hat to support PostgreSQL" appears to me a false
> statement. They are not supporting PostgreSQL, they are supporting
> their version of PostgreSQL on RHL.
That's the service their offering to their paying customers. However, Red
Hat has also allocated development effort to PostgreSQL in general (see the
recent message on -announce), which is something from which all PostgreSQL
users will benefit in the long run.
Ray
--
"The problem with the global village is all the global village idiots."
Paul Ginsparg