Thread: What Linux edition we should chose?
Hi, Currently we use Debian, but it chosen by our OS admnistrator. Now we can change our OS and it is question what Linux edition will be the best. We would like have access to new versions of Postgres as soon as possible, for Debian sometimes we had to wait many weeks for official packages. Regards Michal Szymanski
On Mon, May 31, 2010 at 1:59 PM, Michal Szymanski <dyrex@poczta.onet.pl> wrote: > Hi, > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. > > Regards > Michal Szymanski > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > ArchLinux or Gentoo. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski <dyrex@poczta.onet.pl> wrote: > Hi, > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. Pgsql is pretty easy to build from source.
Michal Szymanski <dyrex@poczta.onet.pl> wrote: > Hi, > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon With which distribution you are familiar? > as possible, for Debian sometimes we had to wait many weeks for > official packages. That's not true, and it's no problem to build PG from source. Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) "If I was god, I would recompile penguin with --enable-fly." (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
2010/5/31 Michal Szymanski <dyrex@poczta.onet.pl>
Hi,
Currently we use Debian, but it chosen by our OS admnistrator. Now we
can change our OS and it is question what Linux edition will be the
best. We would like have access to new versions of Postgres as soon
as possible, for Debian sometimes we had to wait many weeks for
official packages.
Regards
Michal Szymanski
Use whatever you want. I've been compiling PostgreSQL on Ubuntu, Debian and Gentoo so far without any problems.
Choose the distribution that you're familiar with, take PostgreSQL sources and compile as you wish.
regards
Szymon Guz
Szymon Guz
On Mon, 31 May 2010 08:47:25 -0600 Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski > <dyrex@poczta.onet.pl> wrote: > > Hi, > > Currently we use Debian, but it chosen by our OS admnistrator. > > Now we can change our OS and it is question what Linux edition > > will be the best. We would like have access to new versions of > > Postgres as soon as possible, for Debian sometimes we had to > > wait many weeks for official packages. > > Pgsql is pretty easy to build from source. Yeah it is. But what is it going to be an upgrade process? On a production box? Any experience to share on upgrading from source on Debian? -- Ivan Sergio Borgonovo http://www.webthatworks.it
2010/5/31 Ivan Sergio Borgonovo <mail@webthatworks.it>
On Mon, 31 May 2010 08:47:25 -0600Yeah it is. But what is it going to be an upgrade process? On a
Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> <dyrex@poczta.onet.pl> wrote:
> > Hi,
> > Currently we use Debian, but it chosen by our OS admnistrator.
> > Now we can change our OS and it is question what Linux edition
> > will be the best. We would like have access to new versions of
> > Postgres as soon as possible, for Debian sometimes we had to
> > wait many weeks for official packages.
>
> Pgsql is pretty easy to build from source.
production box?
Any experience to share on upgrading from source on Debian?
Usually that's pretty easy: for upgrading the minor version (e.g. from 8.3.1 to 8.3.3) it should be enough to compile the new sources, stop server, run `make install` and run the server with new binaries. Upgrading from 8.3 to 8.4 can be easily done using dump from current version. There is nothing wrong to run the new and old postgres versions parallel so you can copy data from one database to another.
There is also pgmigrator, but I haven't checked that yet.
Remember to make a database dump before the whole operation :)
regards
Szymon Guz
Szymon Guz
Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> On Mon, 31 May 2010 08:47:25 -0600
> Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> Pgsql is pretty easy to build from source.
> Yeah it is. But what is it going to be an upgrade process? On a
> production box?
If it makes you feel better, build your own RPMs (or
$package-style-of-choice). This is actually a pretty good idea if you
are on a package-manager-based platform, as it makes it far simpler to
keep track of exactly what you've got installed. It's generally not
hard to take the source package supplied by your distro and stick a
new minor-release source tarball into it.
regards, tom lane
You should use whatever you are comfortable with. I would go with ArchLinux for its ease of use and making packages. RPM and DPKG are much harder to build than ArchLinux's .pkg.tar.xz Also, if you install some libraries like python clients or some software depending on PgSql from the repositories in RPM/DPKG based OS, you will have a tough time with the dependency stuff. ArchLinux provides a PKGBUILD already from ABS (Arch Build System) which contains all the dependency satisfiers. It serves two purposes- depedency satisfaction and self compilation. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
Le lundi 31 mai 2010 10:23:51, Szymon Guz a écrit : > 2010/5/31 Ivan Sergio Borgonovo <mail@webthatworks.it> > > > On Mon, 31 May 2010 08:47:25 -0600 > > > > Scott Marlowe <scott.marlowe@gmail.com> wrote: > > > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski > > > > > > <dyrex@poczta.onet.pl> wrote: > > > > Hi, > > > > Currently we use Debian, but it chosen by our OS admnistrator. > > > > Now we can change our OS and it is question what Linux edition > > > > will be the best. We would like have access to new versions of > > > > Postgres as soon as possible, for Debian sometimes we had to > > > > wait many weeks for official packages. > > > > > > Pgsql is pretty easy to build from source. > > > > Yeah it is. But what is it going to be an upgrade process? On a > > production box? > > Any experience to share on upgrading from source on Debian? > > Usually that's pretty easy: for upgrading the minor version (e.g. from > 8.3.1 to 8.3.3) it should be enough to compile the new sources, stop > server, run `make install` and run the server with new binaries. Upgrading > from 8.3 to 8.4 can be easily done using dump from current version. There > is nothing wrong to run the new and old postgres versions parallel so you > can copy data from one database to another. > There is also pgmigrator, but I haven't checked that yet. > > Remember to make a database dump before the whole operation :) > > regards > Szymon Guz Me as system architec, sysadmin and manager (gerencial power) jejej :) we have choose Mandriva, it is quite easy to install and to maintain, and speaking about packages there are many support in them, including PGSQL LD
On Mon, May 31, 2010 at 8:17 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski <dyrex@poczta.onet.pl> wrote: >> Hi, >> Currently we use Debian, but it chosen by our OS admnistrator. Now we >> can change our OS and it is question what Linux edition will be the >> best. We would like have access to new versions of Postgres as soon >> as possible, for Debian sometimes we had to wait many weeks for >> official packages. > > Pgsql is pretty easy to build from source. > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > And with ArchLinux its even more easy to keep track of its updates. You don't have to make weird configurations. Just use a PKGBUILD script from ABS (Arch Build System), change some settings, run makepkg and your package is created with the default clean configuration. No /usr/local stuff. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
On Mon, 31 May 2010 17:23:51 +0200 Szymon Guz <mabewlun@gmail.com> wrote: > > Yeah it is. But what is it going to be an upgrade process? On a > > production box? > > Any experience to share on upgrading from source on Debian? > Usually that's pretty easy: for upgrading the minor version (e.g. > from 8.3.1 to 8.3.3) it should be enough to compile the new > sources, stop server, run `make install` and run the server with > new binaries. Upgrading from 8.3 to 8.4 can be easily done using > dump from current version. There is nothing wrong to run the new > and old postgres versions parallel so you can copy data from one > database to another. There is also pgmigrator, but I haven't > checked that yet. That's clear but there are a bunch of small and possibly very annoying details that make deploying in production a bit more challenging than ./configure, make, make install. I admit I only compiled postgres in my /home when I was developing an extension. It is something I do rarely and never on production. If I was thinking to upgrade on a debian box that is already running a packaged version I'd have to understand how deal with debian patches (I think most were related to paths where postgres expect to find it's stuff). Once I understand what all debian patches do I'll try to see if I can avoid them all so that upgrading will be easier the next time. I'll have to see how debian ./configure the package, I'll have to replicate the init.d script for the newer version, take care of making the 2 servers run temporarily on different ports... etc... I could even think of making a .deb I think about it I could even come up with a longer list of things I should do. I bet I'm not the first one that's going to upgrade Debian from source. So someone may share his recipe and caveats. I was actually thinking to test 9.0 in my /home on some real world DB. That could be a chance to learn how to upgrade from source. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote: > if you install some libraries like python clients or some > software depending on PgSql from the repositories in RPM/DPKG based > OS, you will have a tough time with the dependency stuff. Really? -- Devrim Gündüz <devrim@gunduz.org>
On Mon, 2010-05-31 at 08:47 -0600, Scott Marlowe wrote: > Pgsql is pretty easy to build from source. Right, but some sysadmins don't want to see development libraries on the machines. -- Devrim Gündüz <devrim@gunduz.org>
On Mon, 2010-05-31 at 01:29 -0700, Michal Szymanski wrote: > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. It is not "many" weeks actually -- it is just their QA policy. Anyway, I've been running an RPM repository, which has up2date packages, which are releases on the same date as PostgreSQL updates are releases. You may want to consider it, if you are familiar with CentOS,RHEL or Fedora: http://yum.pgrpms.org Regards,Currently we use Debian, but it chosen by our OS admnistrator. Now we can change our OS and it is question what Linux edition will be the best. We would like have access to new versions of Postgres as soon as possible, for Debian sometimes we had to wait many weeks for official packages. -- Devrim Gündüz <devrim@gunduz.org>
On Monday 31 May 2010, Devrim Gündüz <devrim@gunduz.org> wrote: > On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote: > > if you install some libraries like python clients or some > > software depending on PgSql from the repositories in RPM/DPKG based > > OS, you will have a tough time with the dependency stuff. > > Really? > Depends. If you build a compat- RPM to supply the original system-provided client libpq.so it will usually satisfy their package requirements. If you don't, then you might find yourself needing to rebuild other packages to coexist with upgraded PostgreSQL versions. Neither option is terribly difficult to accommodate. -- "No animals were harmed in the recording of this episode. We tried but that damn monkey was just too fast."
On Tue, Jun 1, 2010 at 4:40 AM, Alan Hodgson <ahodgson@simkin.ca> wrote: > On Monday 31 May 2010, Devrim Gündüz <devrim@gunduz.org> wrote: >> On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote: >> > if you install some libraries like python clients or some >> > software depending on PgSql from the repositories in RPM/DPKG based >> > OS, you will have a tough time with the dependency stuff. >> >> Really? >> > > Depends. If you build a compat- RPM to supply the original system-provided > client libpq.so it will usually satisfy their package requirements. If you > don't, then you might find yourself needing to rebuild other packages to > coexist with upgraded PostgreSQL versions. Neither option is terribly > difficult to accommodate. > > -- > "No animals were harmed in the recording of this episode. We tried but that > damn monkey was just too fast." > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > @Devrim: You got the reason from @Alan. Self compilation has the advantage of custom gcc flags like -O3 -march -msse, etc. which can improve performance. Building RPMs is not a task that everyone can do. It requires extensive reading about rpmbuild and writing the specfile. So if you install directly from source without RPM, it won't satisfy the libpq.so dependency, so you cannot install applications using yum. This is not the case with Arch PKGBUILD, because the PKGBUILD is just a bash script. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
Hi, I run debian/testing since years and it is the best in my opinion. Besides the fact that new versions come in quite fast (after the wait phase from unstable to testing) the upgrade for major versions (eg 8.3 to 8.4) is very simple as it does not override the old files but does a parallel install. This is something I do miss from the RPM versions. Because if you do not dump the data before you upgrade, you are quit screwed. On Mon, May 31, 2010 at 17:29, Michal Szymanski <dyrex@poczta.onet.pl> wrote: > Hi, > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. > > Regards > Michal Szymanski > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- ★ Clemens 呉 Schwaighofer ★ IT Engineer/Web Producer/Planning ★ E-Graphics Communications SP Digital ★ 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ★ Tel: +81-(0)3-3545-7706 ★ Fax: +81-(0)3-3545-7343 ★ http://www.e-gra.co.jp This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to disclaimer@tbwaworld.com and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation.
On Tue, Jun 1, 2010 at 6:38 AM, Clemens Schwaighofer <clemens_schwaighofer@e-gra.co.jp> wrote: > Hi, > > I run debian/testing since years and it is the best in my opinion. > Besides the fact that new versions come in quite fast (after the wait > phase from unstable to testing) the upgrade for major versions (eg 8.3 > to 8.4) is very simple as it does not override the old files but does > a parallel install. > > This is something I do miss from the RPM versions. Because if you do > not dump the data before you upgrade, you are quit screwed. > > On Mon, May 31, 2010 at 17:29, Michal Szymanski <dyrex@poczta.onet.pl> wrote: >> Hi, >> Currently we use Debian, but it chosen by our OS admnistrator. Now we >> can change our OS and it is question what Linux edition will be the >> best. We would like have access to new versions of Postgres as soon >> as possible, for Debian sometimes we had to wait many weeks for >> official packages. >> >> Regards >> Michal Szymanski >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> > > > > -- > ★ Clemens 呉 Schwaighofer > ★ IT Engineer/Web Producer/Planning > ★ E-Graphics Communications SP Digital > ★ 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN > ★ Tel: +81-(0)3-3545-7706 > ★ Fax: +81-(0)3-3545-7343 > ★ http://www.e-gra.co.jp > > > This e-mail is intended only for the named person or entity to which > it is addressed and contains valuable business information that is > privileged, confidential and/or otherwise protected from disclosure. > If you received this e-mail in error, any review, use, dissemination, > distribution or copying of this e-mail is strictly prohibited. > Please notify us immediately of the error via e-mail to > disclaimer@tbwaworld.com and please delete the e-mail from your system, retaining no copies in any media. > We appreciate your cooperation. > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > Nope; you're wrong. Even RPM doesn't remove the data. But its always safer to keep a backup. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
On Tue, Jun 1, 2010 at 11:30, Nilesh Govindarajan <lists@itech7.com> wrote: > Nope; you're wrong. Even RPM doesn't remove the data. But its always > safer to keep a backup. I am not talking about removing the data I am talking of not beeing able to access it because the database itself is still in the old version. Unless you use the migrate script, which just started to appear, you had to dump the data, to the rpm upgrade and import the data. I really prefer the debian way where I can run them parallel and therefore test everything before I do a switchover. -- ★ Clemens 呉 Schwaighofer ★ IT Engineer/Web Producer/Planning ★ E-Graphics Communications SP Digital ★ 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ★ Tel: +81-(0)3-3545-7706 ★ Fax: +81-(0)3-3545-7343 ★ http://www.e-gra.co.jp This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to disclaimer@tbwaworld.com and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation.
Michal Szymanski wrote: > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. > Yes, Debian QA can take a couple of weeks for things to reach you after release. From some perspectives that's considered a good thing. If the update is to fix a security bug, it's possible that's a problem instead. In that rare case, you can always learn to build your own packages. Ultimately, if your true priority is "access to new versions of Postgres as soon as possible", you can do that on any Linux distribution by building from source and potentially packaging the result up as if it were a standard packages. That should be way, way down on the list of things that factor into what version of Linux you deploy though. If you've got support from your administration team using Debian, I think you'd be crazy to switch to another OS just to speed up getting newer versions of PostgreSQL. Put a little time into learning how to build your own packages instead, to work around this one perceived flaw, and you'll be way ahead of the mess that comes with switching distributions altogether. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On Tuesday 01 June 2010 03.08:06 Clemens Schwaighofer wrote: > Besides the fact that new versions come in quite fast (after the wait > phase from unstable to testing) ... and you can always mix testing and unstable. If your testing installation is not too old, usually not much fiddling with dependencies is involved. Reading the apt_preferences manual page and some other Debian documentation to understand how packages are moved between experimental/unstable/testing is strongly recommended, though. I'd hesitate to use unstable for a production machine, though. Even testing is not always a good idea, since security support for testing is not quite as good as for stable. (shameless plug, since we're speaking of Debian ...: <http://blog.fortytwo.ch/archives/84-Order-Your-Debian-Swirl-Umbrella-Now.html>) cheers -- vbi -- Why on earth should we teach children that they are not allowed to share the toys. -- Patrick Harvie, Member of the Scottish Parliament Speaking at Debconf7
Attachment
Heyho! On Tuesday 01 June 2010 06.01:02 Greg Smith wrote: > Put a little time into learning how to build > your own packages instead, to work around this one perceived flaw, and > you'll be way ahead of the mess that comes with switching distributions > altogether. Note that we can always use more people to help Debian, too. If you feel Debian is too slow uploading new pg versions [1]: perhaps you can change this by helping Martin preparing and testing new packages. Packaging stuff for Debian is not magic, it's just Makefiles, Perl/shell scripts and stuff like this. (And I, too, like the parallel installation of different pg versions and was very much missing it when I was forced to work on SuSE for some business stuff...) cheers -- vbi [1] (you did look at "unstable" and "experimental"? The stable releases are quite slow, that's true.) -- featured link: http://www.pool.ntp.org
Attachment
Hi, On Tue, 2010-06-01 at 06:59 +0530, Nilesh Govindarajan wrote: > Self compilation has the advantage of custom gcc flags like -O3 -march > -msse, etc. which can improve performance. I started to think that you have zero idea about building binary packages. > Building RPMs is not a task that everyone can do. It requires > extensive reading about rpmbuild and writing the specfile. Really? http://people.planetpostgresql.org/devrim/index.php?/archives/44-How-To-Build-Your-Own-PostgreSQL-and-related-software-RPMs-on-CentOSRHELFedora.html I can't see anything except svn co and make build there. Do you still need an extensive reading? > So if you install directly from source without RPM, it won't satisfy > the libpq.so dependency, so you cannot install applications using yum. > This is not the case with Arch PKGBUILD, because the PKGBUILD is just > a bash script. Now I'm sure that you don't have any idea about PostgreSQL RPM packages: http://svn.pgrpms.org/browser/rpm/redhat/8.4/compat-postgresql/EL-5 might give you a clue. You may think that ArchLinux is fine for you, but please pick up correct arguments for RPMs first. Devrim - The RPM Packager -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
On Tue, 2010-06-01 at 07:20 +0200, Adrian von Bidder wrote: > Packaging stuff for Debian is not magic, it's just Makefiles, > Perl/shell scripts and stuff like this. Given that *even I* ( :P ) could build a few 8.2 .deb packages for my previous employer, I also want to confirm that building .debs are not that hard. -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
2010/6/1 Devrim GÜNDÜZ <devrim@gunduz.org>: > Hi, > > On Tue, 2010-06-01 at 06:59 +0530, Nilesh Govindarajan wrote: >> Self compilation has the advantage of custom gcc flags like -O3 -march >> -msse, etc. which can improve performance. > > I started to think that you have zero idea about building binary > packages. > >> Building RPMs is not a task that everyone can do. It requires >> extensive reading about rpmbuild and writing the specfile. > > Really? > > http://people.planetpostgresql.org/devrim/index.php?/archives/44-How-To-Build-Your-Own-PostgreSQL-and-related-software-RPMs-on-CentOSRHELFedora.html > > I can't see anything except svn co and make build there. Do you still > need an extensive reading? > >> So if you install directly from source without RPM, it won't satisfy >> the libpq.so dependency, so you cannot install applications using yum. >> This is not the case with Arch PKGBUILD, because the PKGBUILD is just >> a bash script. > > Now I'm sure that you don't have any idea about PostgreSQL RPM packages: > > http://svn.pgrpms.org/browser/rpm/redhat/8.4/compat-postgresql/EL-5 > > might give you a clue. > > You may think that ArchLinux is fine for you, but please pick up correct > arguments for RPMs first. > > Devrim - The RPM Packager > -- > Devrim GÜNDÜZ > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > PostgreSQL RPM Repository: http://yum.pgrpms.org > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > @Devrim, I may be wrong at sometimes, because I have not done any qualification research on this. All I have learned from Google and self experience. I run my site (see my signature) on a self managed VPS. I was using the default PGSQL RPM from the fedora repository, the site was getting way slow. So I compiled all the stuff apache, php and postgresql with custom gcc flags, which improved performance like hell. This may not apply to all, its my experience; not an illusion because I asked other site contributors also about the speed, they said it was much better. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com
2010/5/31 Nilesh Govindarajan <lists@itech7.com>: > I run my site (see my signature) on a self managed VPS. I was using > the default PGSQL RPM from the fedora repository, the site was getting > way slow. So I compiled all the stuff apache, php and postgresql with > custom gcc flags, which improved performance like hell. > This may not apply to all, its my experience; not an illusion because > I asked other site contributors also about the speed, they said it was > much better. I have fond memories of having a single script to do all that on RedHat 5.1 back when I started out. (Not RHEL 5.1, RedHat 5.1) Honestly, for our single purpose corporate intranet machine it was perfection, and that machine ran 24/7 for years after I left with only minor maintenance. We were on RedHat 9 or something when I left. I still build mutliple builds of pgsql, now on RHEL 5.latest, and it's pretty easy. I just make a configure.local file, use that for each new version etc so it's just like the last. But for php I use eaccelerator and it's a necessity even with powerful servers. Drops load on heavy web servers by factors of 10 or 20.
On 05/31/2010 01:29 AM, Michal Szymanski wrote: > Hi, > Currently we use Debian, but it chosen by our OS admnistrator. Now we > can change our OS and it is question what Linux edition will be the > best. We would like have access to new versions of Postgres as soon > as possible, for Debian sometimes we had to wait many weeks for > official packages. > Some thoughts: If the machine is only used as a database server, consider Red Hat Enterprise Linux/CentOS. They are great for installing and keeping up-to-date - just add the PGDG repo into the yum repos configuration files. It matters not if I'm on 5.1, 5.2, 5.3... The updates to the RPMs tend to become available concurrently with source releases and the file/directory/path settings tend to follow PostgreSQL's worldview. But if the machine is used for multiple purposes you may be frustrated by the long-term stable nature of RH. For example, if you plan on using PHP on the same machine you will need to stick with the RH default version which is a couple releases old or go through the hassle of configuring/compiling PHP or locating third-party RPMs - PHP does not supply RPMs. Ubuntu, with its 6-month release cycle, tends to include more recent versions of software. But there is a delay getting updates and it is more of a headache installing new PostgreSQL on older Ubuntu. There isn't a nice, neat source for PGDG vetted .debs. You will also get an installation tailored for the Debian/Ubuntu view of where files should go. On the other hand, this structure lends itself nicely to running different major versions in parallel and they provide some scripts to handle major-version upgrades. The scripts have worked for me but YMMV. At least the old installation is still available if the upgrade fails. Cheers, Steve
In response to Steve Crawford <scrawford@pinpointresearch.com>: > On 05/31/2010 01:29 AM, Michal Szymanski wrote: > > Hi, > > Currently we use Debian, but it chosen by our OS admnistrator. Now we > > can change our OS and it is question what Linux edition will be the > > best. We would like have access to new versions of Postgres as soon > > as possible, for Debian sometimes we had to wait many weeks for > > official packages. If you're not married to Linux, FreeBSD does an excellent job of keeping up to date with both PostgreSQL and PHP. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/
On 1 Jun 2010, at 22:03, Bill Moran wrote: > In response to Steve Crawford <scrawford@pinpointresearch.com>: > >> On 05/31/2010 01:29 AM, Michal Szymanski wrote: >>> Hi, >>> Currently we use Debian, but it chosen by our OS admnistrator. Now we >>> can change our OS and it is question what Linux edition will be the >>> best. We would like have access to new versions of Postgres as soon >>> as possible, for Debian sometimes we had to wait many weeks for >>> official packages. > > If you're not married to Linux, FreeBSD does an excellent job of keeping > up to date with both PostgreSQL and PHP. I totally agree with that. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:737,4c0599a810154434717690!
Nilesh Govindarajan wrote: > I run my site (see my signature) on a self managed VPS. I was using > the default PGSQL RPM from the fedora repository, the site was getting > way slow. So I compiled all the stuff apache, php and postgresql with > custom gcc flags, which improved performance like hell Without breaking down how much of that speed increase was from Apache, PHP, and PostgreSQL respectively, I'm not sure what the people who package PostgreSQL can really learn from your data here. Reports on improving PostgreSQL performance by tweaking optimizer flags haven't been very repeatable for others when they've popped up in the past, so for all we know the bulk of your gain came from Apache and PHP optimizations. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On Wed, Jun 02, 2010 at 01:32:44AM -0400, Greg Smith wrote: > Nilesh Govindarajan wrote: > >I run my site (see my signature) on a self managed VPS. I was using > >the default PGSQL RPM from the fedora repository, the site was getting > >way slow. So I compiled all the stuff apache, php and postgresql with > >custom gcc flags, which improved performance like hell And were the versions the same? If you're going to go to the trouble of hand-compiling, I'm willing to bet that you went to the trouble of finding more recent versions of the software. That is not how you test things. > > Without breaking down how much of that speed increase was from > Apache, PHP, and PostgreSQL respectively, I'm not sure what the > people who package PostgreSQL can really learn from your data here. > Reports on improving PostgreSQL performance by tweaking optimizer > flags haven't been very repeatable for others when they've popped up > in the past, so for all we know the bulk of your gain came from > Apache and PHP optimizations. Not to mention that compiler optimizations increase the chance of hitting a compiler bug. Getting the wrong answer fast is not an improvement over the right answer slow. > > -- > Greg Smith 2ndQuadrant US Baltimore, MD > PostgreSQL Training, Services and Support > greg@2ndQuadrant.com www.2ndQuadrant.us > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general
On Wednesday 02 June 2010 07.51:50 Bret S. Lambert wrote: > Getting the wrong answer fast is not an > improvement over the right answer slow. Doesn't match reality. Listened to any politicians lately? (sorry, couldn't resist.) -- vbi -- In seiner mit Hochspannung erwarteten Rede zur Lage der Nation hat US-Präsident George W. Bush heute früh angekündigt, Außenminister Colin Powell nächste Woche klare Beweise dafür ankündigen zu lassen, daß Beweise für unwiderlegbare Beweise vorlägen.
Attachment
2010/5/31 Devrim Gündüz <devrim@gunduz.org>: > On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote: >> if you install some libraries like python clients or some >> software depending on PgSql from the repositories in RPM/DPKG based >> OS, you will have a tough time with the dependency stuff. > > Really? > My experience (mostly with FreeBSD, but it scales to other systems as well) is that if you have some stuff managed by your package manager and some from hand-built sources, that ultimately you end up in a world of hurt. It has to be all or none one way or the other, or your package manager will try to install things you already have, possibly breaking how you set things up, or you end up with missing bits and pieces. We choose to make packages locally to satisfy all of our dependencies as it also greatly simplifies management across 30+ servers.
On Monday 31 May 2010 10.29:22 Michal Szymanski wrote: > for Debian sometimes we had to wait many weeks for > official packages. FWIW: I've just noticed that Debian experimental carries pg 9.0beta1, it was uploaded 3.5., so thats not bad, taking into account that it was released only a few days earlier. http://packages.debian.org/experimental/postgresql-9.0 Experiemntal packages can be installed directly into Debian unstable (sid) installations and can often be recompiled rather trivially into Debian testing. Depending on how old Debian stable is, compiling there may take a bit more work (especially for building the stuff depending on the not so slowly moving targets like python, ruby etc.) but is certainly doable. Not that I'd recommend using beta packages from experimental on a production system. cheers -- vbi -- Sterility is inherited. If your parents never had kids, odds are you wont either. -- William R. James in news.admin.net-abuse.email
Attachment
Michal Szymanski <dyrex@poczta.onet.pl> writes:
> Hi,
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
> as possible, for Debian sometimes we had to wait many weeks for
> official packages.
I'd consider Debian to be a perfectly reasonable choice...
In order to conclude that something else is specifically superior,
you'd need to define some metrics that allow evaluating along the
lines that:
"A is better than B in areas X and Y.
B is better than A in area Z.
Because factor Z is really important to us, that means we prefer
distribution B."
Absent of evaluation criteria, you'll just see people saying "Oh, I
like {SomeThing} about my favorite distribution, and maybe you'd like
that too."
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxfinances.info/info/finances.html
Rules of the Evil Overlord #189. "I will never tell the hero "Yes I
was the one who did it, but you'll never be able to prove it to that
incompetent old fool." Chances are, that incompetent old fool is
standing behind the curtain." <http://www.eviloverlord.com/>
On Wed, Jun 2, 2010 at 7:44 PM, Adrian von Bidder <avbidder@fortytwo.ch> wrote: > On Monday 31 May 2010 10.29:22 Michal Szymanski wrote: >> for Debian sometimes we had to wait many weeks for >> official packages. > > Experiemntal packages can be installed directly into Debian unstable (sid) > installations and can often be recompiled rather trivially into Debian > testing. Depending on how old Debian stable is, compiling there may take a > bit more work (especially for building the stuff depending on the not so > slowly moving targets like python, ruby etc.) but is certainly doable. As many other people have this idea, you can just re-use their back-porting work: backports.org Never had a quality issue with these packages and updates are quickly available. YMMV. -- Kind regards, Mathieu
On 06/01/2010 03:34 AM, Tom Lane wrote: > Ivan Sergio Borgonovo <mail@webthatworks.it> writes: >> On Mon, 31 May 2010 08:47:25 -0600 >> Scott Marlowe <scott.marlowe@gmail.com> wrote: >>> Pgsql is pretty easy to build from source. > >> Yeah it is. But what is it going to be an upgrade process? On a >> production box? > > If it makes you feel better, build your own RPMs (or > $package-style-of-choice). This is actually a pretty good idea if you > are on a package-manager-based platform, as it makes it far simpler to > keep track of exactly what you've got installed. It's generally not > hard to take the source package supplied by your distro and stick a > new minor-release source tarball into it. Amen. We do this for anything not supplied with RHEL, although our first trip is usually a quick look at the EPEL repos to see if they have a suitable build we can use. As an aside, though, I personally gave up the gotta-have-the-latest treadmill some time ago. There's a lot to be said for letting a distribution engineering team spend the time and effort tracking security fixes and suchlike. (And to answer the original question, I'd use RHEL or CentOS; but these things tend to devolve into a simple way of exposing the distro prejudices of the responders)