Using pre-configured vs building Postgres

[Armin Resch]

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

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

[Tom Lane]

Post by Armin Resch
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

[Armin Resch]

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.
-ar

On Mon, Jan 7, 2013 at 12:37 PM, Tom Lane <***@sss.pgh.pa.us> wrote:

[Kevin Grittner]

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

[Armin Resch]

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

Post by Kevin Grittner

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