Обсуждение: Using pre-configured vs building Postgres
Hi all,
I am running custom applications on a Linux platform which essentially have Perl and Postgres as prerequisites. In the past, we used an arcane Linux distro which left me with no other option than to build Perl + 50 odd CPAN modules + Postgres myself. I prefixed the stack under a common path like this:
/osstack/perl/5.12.1
/osstack/postgresql/9.0.4
Yet, now, we switch to a more modern distro (OpenSuse 12.1), which does have the RPM for Perl 5.14.2 pre-installed with the option to install more RPMs such as
perl-DBI-1.616-7.1.3
perl-DBD-Pg-2.18.0-3.1.4
postgresql-9.1.1-3.1.4
postgresql-9.1.1-3.1.4
Once our custom applications are tested and behave, the idea is to freeze all prerequisites until we go to a different generation (potentially different distro altogether in >= 5 years).
Before I try to obtain a handful of CPAN modules which are missing or 'unsupported' in OpenSuse, my question to this admin forum is what pro's and con's to consider when deciding whether to use a pre-configured postgresql versus building it ourselves.
Best,
-ar
Armin Resch <reschab@gmail.com> writes: > Yet, now, we switch to a more modern distro (OpenSuse 12.1), which does > have the RPM for Perl 5.14.2 pre-installed with the option to install more > RPMs such as > perl-DBI-1.616-7.1.3 > perl-DBD-Pg-2.18.0-3.1.4 > postgresql-9.1.1-3.1.4 > Once our custom applications are tested and behave, the idea is to freeze > all prerequisites until we go to a different generation (potentially > different distro altogether in >= 5 years). > Before I try to obtain a handful of CPAN modules which are missing or > 'unsupported' in OpenSuse, my question to this admin forum is what pro's > and con's to consider when deciding whether to use a pre-configured > postgresql versus building it ourselves. Well, if you're starting deployment now with a five-year plan, it's pretty dumb not to be using the latest major release (ie 9.2). 9.1 will be out of support in four years. But even if 9.1 is the release series you want to freeze on, it does not speak well at all for OpenSUSE's update practices if they're still shipping 9.1.1. That's more than a year out of date, and has assorted known security and data-loss issues, cf http://www.postgresql.org/docs/9.1/static/release.html If that's actually the latest version available from them, you'd be very well advised to use your own build of PG instead, and pay attention to our update releases. I can't speak to the question of whether their Perl packages are equally out of date --- you might be all right using those. regards, tom lane
Thx, Tom. OpenSUSE's most recent postgres 9.1 is 9.1.6. Yet, 9.1.1 is what was part of the opensuse12.1 snapshot of RPMs on top of which some of our engineers develop proprietary apps. It worked well for them to freeze an RPM repo because it can happen (and did happen!) that upgrading an individual RPM snow-balled due to package dependencies and eventually broke a proprietary app. It's unfortunate timing that 9.1.1 was the version at the time of the freeze. So, I guess, one needs to evaluate to what extent an upgrade of postgres is contained (e.g. nothing else but perl-DBD::Pg) OR weigh the effort against building it from source.
Armin Resch wrote: > one needs to evaluate to what extent an upgrade of postgres is contained PostgreSQL minor releases (where the version number matches to the left of the second dot) only contain fixes for bugs and security vulnerabilities. Dependencies on other packages should not change. http://www.postgresql.org/support/versioning/ -Kevin
Indeed, 9.1.1 produced log entries complaining about a non-existent schema which clearly exists, and I confirmed 9.1.6 behaves.
...
2013-01-10 15:49:45.068 CST - - 50ef3779.377: WARNING: invalid value for parameter "search_path": "beverlyhills, public"
2013-01-10 15:49:45.068 CST - - 50ef3779.377: DETAIL: schema "beverlyhills" does not exist
2013-01-10 15:50:15.080 CST - - 50ef3797.394: WARNING: invalid value for parameter "search_path": "beverlyhills, public"
2013-01-10 15:50:15.080 CST - - 50ef3797.394: DETAIL: schema "beverlyhills" does not exist
2013-01-10 15:50:30.082 CST - - 50ef37a6.3a3: WARNING: invalid value for parameter "search_path": "beverlyhills, public"
2013-01-10 15:50:30.083 CST - - 50ef37a6.3a3: DETAIL: schema "beverlyhills" does not exist
2013-01-10 15:50:45.124 CST - - 50ef37b5.3b1: WARNING: invalid value for parameter "search_path": "beverlyhills, public"
2013-01-10 15:50:45.125 CST - - 50ef37b5.3b1: DETAIL: schema "beverlyhills" does not exist
...
-ar
On Wed, Jan 9, 2013 at 3:59 PM, Kevin Grittner <kgrittn@mail.com> wrote:
Armin Resch wrote:
> one needs to evaluate to what extent an upgrade of postgres is contained
PostgreSQL minor releases (where the version number matches to the
left of the second dot) only contain fixes for bugs and security
vulnerabilities. Dependencies on other packages should not change.
http://www.postgresql.org/support/versioning/
-Kevin