Re: 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(at)poczta(dot)onet(dot)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(at)postgresql(dot)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(at)poczta(dot)onet(dot)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.

On Mon, May 31, 2010 at 8:17 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski <dyrex(at)poczta(dot)onet(dot)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(at)postgresql(dot)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

Michal Szymanski <dyrex(at)poczta(dot)onet(dot)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(at)poczta(dot)onet(dot)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

On Mon, 31 May 2010 08:47:25 -0600
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:

> On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> <dyrex(at)poczta(dot)onet(dot)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(at)webthatworks(dot)it>

> On Mon, 31 May 2010 08:47:25 -0600
> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>
> > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> > <dyrex(at)poczta(dot)onet(dot)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

Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> writes:
> On Mon, 31 May 2010 08:47:25 -0600
> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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(at)webthatworks(dot)it>
>
> > On Mon, 31 May 2010 08:47:25 -0600
> >
> > Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> > > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> > >
> > > <dyrex(at)poczta(dot)onet(dot)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, 31 May 2010 17:23:51 +0200
Szymon Guz <mabewlun(at)gmail(dot)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(at)gunduz(dot)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(at)gunduz(dot)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(at)gunduz(dot)org>

On Monday 31 May 2010, Devrim Gündüz <devrim(at)gunduz(dot)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."

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(at)poczta(dot)onet(dot)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(at)postgresql(dot)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(at)tbwaworld(dot)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 4:40 AM, Alan Hodgson <ahodgson(at)simkin(dot)ca> wrote:
> On Monday 31 May 2010, Devrim Gündüz <devrim(at)gunduz(dot)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(at)postgresql(dot)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

On Tue, Jun 1, 2010 at 6:38 AM, Clemens Schwaighofer
<clemens_schwaighofer(at)e-gra(dot)co(dot)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(at)poczta(dot)onet(dot)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(at)postgresql(dot)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(at)tbwaworld(dot)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(at)postgresql(dot)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(at)itech7(dot)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(at)tbwaworld(dot)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(at)2ndQuadrant(dot)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

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

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

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

2010/6/1 Devrim GÜNDÜZ <devrim(at)gunduz(dot)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(at)itech7(dot)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(at)pinpointresearch(dot)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(at)pinpointresearch(dot)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(at)2ndQuadrant(dot)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(at)2ndQuadrant(dot)com www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)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.

2010/5/31 Devrim Gündüz <devrim(at)gunduz(dot)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.

Michal Szymanski <dyrex(at)poczta(dot)onet(dot)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 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

On Wed, Jun 2, 2010 at 7:44 PM, Adrian von Bidder <avbidder(at)fortytwo(dot)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(at)webthatworks(dot)it> writes:
>> On Mon, 31 May 2010 08:47:25 -0600
>> Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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)