Обсуждение: Postgresql 8.0 or 8.1 vs. latest Red Hat RPM
I'm in the midst of a knock-down-drag-out with a sysadmin (who, somewhat unfortunately, is also a good friend) over how to administer Postgresql on some new machines we've got in.
My argument is we should use the latest stable version of Postgres. His take is we ought to use the latest version provided by Red Hat. (This is for a set of Red Hat Enterprise boxes.)
Normally, I'd just say do what you want in production, I'll do what I want in development, and we'll settle the differences in committee. But, since we've finally got perfectly mirrored hardware, we'd like to see the same in software.
Any particularly compelling arguments or points would be valuable, either way.
One point of contention in this argument seems to be the notion that Red Hat ports security fixes to older versions, even if it has to do this itself. I don't necessarily believe that this happens. That is, imagine that there's some fix that makes it into the 8.x branch. For whatever reason, this doesn't go into 7.x. Red Hat is still using the 7.x branch, so it undertakes to do this work itself. Does that sort of thing really happen?
Is there a general performance improvement from 7 to 8? What about reliability improvements?
For how long is the 7.x branch going to be under maintenance and development (by the community, not be Red Hat)? Is there even a time frame?
Again, any thoughts appreciated.
Thanks,
Colin
> > Is there a general performance improvement from 7 to 8? What about > reliability improvements? > > For how long is the 7.x branch going to be under maintenance and > development (by the community, not be Red Hat)? Is there even a time > frame? > > Again, any thoughts appreciated. > Use the latest stable from the PostgreSQL community. If you have management that wants "Supported releases" get the MammothPostgreSQL RPMS over at http://www.mammothpostgresql.org as they are supported by CMD (my company) . Sincerely, Joshua D. Drake > Thanks, > Colin
Hi, On Tue, 2006-02-07 at 18:09 -0500, Colin Freas wrote: > My argument is we should use the latest stable version of Postgres. > His take is we ought to use the latest version provided by Red Hat. > (This is for a set of Red Hat Enterprise boxes.) AFAIK, if you want support from Red Hat, you have to use the packages provided by Red Hat. If you use any 3rd party or unsupported packages, they won't support your system. So it depends on you. We provide RPMs for RHEL boxes: http://www.postgresql.org/ftp/binary/ Also Command Prompt announced a PostgreSQL distribution that has RPMs for RHEL 3 and 4: http://www.mammothpostgresql.org/ > One point of contention in this argument seems to be the notion that > Red Hat ports security fixes to older versions, even if it has to do > this itself. I don't necessarily believe that this happens. That is, > imagine that there's some fix that makes it into the 8.x branch. For > whatever reason, this doesn't go into 7.x. Red Hat is still using the > 7.x branch, so it undertakes to do this work itself. Does that sort > of thing really happen? Red Hat is still using 7.X in RHEL because 8.0 was very fresh when RHEL 4 was released and I think they thought that it is not tested enough for Enterprise Linux. Also, Red Hat does not update to new major version via up2date. This is their policy that I strongly support. > Is there a general performance improvement from 7 to 8? What about > reliability improvements? Sure. 8.0 was a revolutinary step. > For how long is the 7.x branch going to be under maintenance and > development (by the community, not be Red Hat)? Is there even a time > frame? 7.2 is now unsupported. Since Red Hat uses 7.3 in RHEL3, they (and so Tom Lane, core developer of PostgreSQL) will continue supporting it. That means 7.3 will be supported at least 2-3 years more. I'm not sure about the exact EOL of 7.4. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Devrim GUNDUZ <devrim@commandprompt.com> writes: > On Tue, 2006-02-07 at 18:09 -0500, Colin Freas wrote: >> My argument is we should use the latest stable version of Postgres. >> His take is we ought to use the latest version provided by Red Hat. >> (This is for a set of Red Hat Enterprise boxes.) > AFAIK, if you want support from Red Hat, you have to use the packages > provided by Red Hat. If you use any 3rd party or unsupported packages, > they won't support your system. So it depends on you. As the main guy on the hook for that support from Red Hat ;-), the above is true as far as it goes, but on the whole I'd have to say that you are probably better off using the latest community release and relying on the community mailing lists for support. The RHEL releases are targeted at people who froze their application platforms a year ago (for RHEL4) or more than that (for RHEL3), so if you are just now choosing your platform then neither scenario fits you --- so unless you want to wait for RHEL5 you're sort of falling between the cracks. Red Hat is not unaware of this gap, and is close on to introducing support for PG 8.1 in RHEL4, but it'll be separate from the base RHEL4 product ... and it won't be out for a month or two. http://www.redhat.com/magazine/015jan06/departments/red_hat_speaks/ regards, tom lane
Colin Freas <colinfreas@gmail.com> writes:
> One point of contention in this argument seems to be the notion that Red Hat
> ports security fixes to older versions, even if it has to do this itself. I
> don't necessarily believe that this happens.
Just for the record, Red Hat sees to it that this happens. The main
reason that you are still seeing update releases out of community CVS
for PG 7.3 is that I am on the hook to maintain 7.3 for RHEL3, and it's
clear to all concerned that making those critical patches in community
CVS first is a low-cost, widely-useful way to get it done.
> Is there a general performance improvement from 7 to 8? What about
> reliability improvements?
Yes, and yes. The commitment for 7.3 is to fix critical problems,
not marginal bugs, and definitely not mere performance issues.
regards, tom lane
I would always use the latest stable release from the PG project for four reasons: a) Databases are notoriously difficult to upgrade once they are in production and have live data. This is especially true if, like us at kieser.net, you run PG databases that are 24/7 business critical and in constant, high volume use. Taking down a database for upgrading just is not an option if only because of the risk that something, however innocuous it may seem in the release notes, may cause a live, production level data fault. The worst scenario is that this happens and it's not detected. So, if you have the chance now, get on the latest version. b) The dev team just keeps on making this wonderful DB better. Every release is a gem and well worth having. c) PG runs on RedHat no problems. Besides which, in the real world, if something goes wrong, chances are you will have to fix it yourself anyway, or asking us here on this list how to fix it.. In the real world, a support contract is nearly never used and in OpenSource, Google and lists such as this are far more efficient in getting answers than most commercial support lines! I know I could get flamed for this, but just passing on my experience. d) Most importantly: You WILL be testing the new PG release in addition to the new servers that you intend to roll out THOROUGHLY because you roll out new kit, won't you? You never, ever roll out anything in production without having properly QAed it, and I am very certain that you will be doing this. nudge. prod. Incidentally, we use Xen and are rolling out DRBD for disk-level mirroring. Xen makes life so much easier... you simply migrate the live machine to another bit of hardware in the event of a fault or maintenance requirements and the performance is near native. It also means that if you need to do heavy handed load balancing you can, but best of all, you can create and test a Xen installation, then use it as the source of clones... so that you are absolutely guaranteed that the machine you have tested is the set of machines that you roll out. That alone is worth running all production machines in Xen. Money simply cannot put a value on that peace of mind. Brad Devrim GUNDUZ wrote: > Hi, > > On Tue, 2006-02-07 at 18:09 -0500, Colin Freas wrote: > > >> My argument is we should use the latest stable version of Postgres. >> His take is we ought to use the latest version provided by Red Hat. >> (This is for a set of Red Hat Enterprise boxes.) >> > > AFAIK, if you want support from Red Hat, you have to use the packages > provided by Red Hat. If you use any 3rd party or unsupported packages, > they won't support your system. So it depends on you. > > We provide RPMs for RHEL boxes: > > http://www.postgresql.org/ftp/binary/ > > Also Command Prompt announced a PostgreSQL distribution that has RPMs > for RHEL 3 and 4: > > http://www.mammothpostgresql.org/ > > >> One point of contention in this argument seems to be the notion that >> Red Hat ports security fixes to older versions, even if it has to do >> this itself. I don't necessarily believe that this happens. That is, >> imagine that there's some fix that makes it into the 8.x branch. For >> whatever reason, this doesn't go into 7.x. Red Hat is still using the >> 7.x branch, so it undertakes to do this work itself. Does that sort >> of thing really happen? >> > > Red Hat is still using 7.X in RHEL because 8.0 was very fresh when RHEL > 4 was released and I think they thought that it is not tested enough for > Enterprise Linux. > > Also, Red Hat does not update to new major version via up2date. This is > their policy that I strongly support. > > >> Is there a general performance improvement from 7 to 8? What about >> reliability improvements? >> > > Sure. 8.0 was a revolutinary step. > > >> For how long is the 7.x branch going to be under maintenance and >> development (by the community, not be Red Hat)? Is there even a time >> frame? >> > > 7.2 is now unsupported. Since Red Hat uses 7.3 in RHEL3, they (and so > Tom Lane, core developer of PostgreSQL) will continue supporting it. > That means 7.3 will be supported at least 2-3 years more. I'm not sure > about the exact EOL of 7.4. > > Regards, >
Hello list,
Bradley Kieser wrote:
> I would always use the latest stable release from the PG project for
> four reasons:
> a) Databases are notoriously difficult to upgrade once they are in [ ... ]
>
> b) The dev team just keeps on making this wonderful DB better. Every
> release is a gem and well worth having.
>
> c) PG runs on RedHat no problems. Besides which, in the real world, if [ ... ]
>
> d) Most importantly: You WILL be testing the new PG release in addition [ ... ]
Your arguments convinced me to use latest stable PostgreSQL database.
I use CentOS 4.x (as you know it is RHEL4 compatibile) and I have
successfuly installed PostgreSQL 8.1.2 from www.postgresql.org.
And now, if I need PostgreSQL as a base for PHP aplication? Package
php-pgsql-4.3.9-3.9.rpm (distributed with CentOS/RHEL) will be works
with PostgreSQL 8.1.2?
Regards
--
__________________________________________________________________
D o m i n i k S k ł a d a n o w s k i
Hi, On Thu, 2006-02-09 at 23:58 +0100, Dominik Składanowski wrote: > And now, if I need PostgreSQL as a base for PHP aplication? Package > php-pgsql-4.3.9-3.9.rpm (distributed with CentOS/RHEL) will be works > with PostgreSQL 8.1.2? No. You'll need our compat RPM: http://developer.postgresql.org/~devrim/rpms/compat/ There are 2 RPMs for 32 and 64 bit platforms. Pick up one. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
> > And now, if I need PostgreSQL as a base for PHP aplication? Package > > php-pgsql-4.3.9-3.9.rpm (distributed with CentOS/RHEL) will be works > > with PostgreSQL 8.1.2? > > No. You'll need our compat RPM: > > http://developer.postgresql.org/~devrim/rpms/compat/ > > There are 2 RPMs for 32 and 64 bit platforms. Pick up one. Thank you. Regards. -- __________________________________________________________________ D o m i n i k S k ł a d a n o w s k i
Dominik Składanowski wrote: > Hello list, > > Bradley Kieser wrote: > >> I would always use the latest stable release from the PG project for >> four reasons: >> a) Databases are notoriously difficult to upgrade once they are in [ ... ] >> >> b) The dev team just keeps on making this wonderful DB better. Every >> release is a gem and well worth having. >> >> c) PG runs on RedHat no problems. Besides which, in the real world, if [ ... ] >> >> d) Most importantly: You WILL be testing the new PG release in addition [ ... ] >> > > Your arguments convinced me to use latest stable PostgreSQL database. > I use CentOS 4.x (as you know it is RHEL4 compatibile) and I have > successfuly installed PostgreSQL 8.1.2 from www.postgresql.org. > > Cool. Hope you are very happy with the decision. > And now, if I need PostgreSQL as a base for PHP aplication? Package > php-pgsql-4.3.9-3.9.rpm (distributed with CentOS/RHEL) will be works > with PostgreSQL 8.1.2? > > I am not familiar with that particular RPM so can't comment, unfortunately. But in general, I have found that all the php-pgsql rpms work with the PG 8.x releases. I have not yet had any problems. Maybe someone else on the list knows of any problems? Beware thought, of older PHP4 releases as there was a fairly nasty bug in the IMAP handling. > Regards > -- > __________________________________________________________________ > D o m i n i k S k ł a d a n o w s k i > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Hi Devrim, For the sake of people like me, can you please explain a little further why you say that you need these RPMs? Just out of interest and to increase the resident knowledge pool as I for one am not aware of any problems so at least one person will learn from your posting! Thank you for your time, Brad Devrim GUNDUZ wrote: > Hi, > > On Thu, 2006-02-09 at 23:58 +0100, Dominik Składanowski wrote: > > >> And now, if I need PostgreSQL as a base for PHP aplication? Package >> php-pgsql-4.3.9-3.9.rpm (distributed with CentOS/RHEL) will be works >> with PostgreSQL 8.1.2? >> > > No. You'll need our compat RPM: > > http://developer.postgresql.org/~devrim/rpms/compat/ > > There are 2 RPMs for 32 and 64 bit platforms. Pick up one. > > Regards, >
Hi,
On Fri, 2006-02-10 at 10:18 +0000, Bradley Kieser wrote:
> For the sake of people like me, can you please explain a little further
> why you say that you need these RPMs?
> Just out of interest and to increase the resident knowledge pool as I
> for one am not aware of any problems so at least one person will learn
> from your posting!
RHEL 3 and RHEL 4 PHP RPMs are compiled with libpq.so.3 . However,
beginning from 8.0.2, libpq was bumped to version 4. So this broke
compatibility between the packages from PostgreSQL.org and RHEL PHP.
In order to solve that problem, we built a compatibility RPM which
installs libpq.so.3 and other libs to your system:
# rpm -ql compat-postgresql-libs
/usr/lib64/libecpg.so.4
/usr/lib64/libecpg.so.4.1
/usr/lib64/libecpg_compat.so.1
/usr/lib64/libecpg_compat.so.1.2
/usr/lib64/libpgtypes.so.1
/usr/lib64/libpgtypes.so.1.2
/usr/lib64/libpq.so.3
/usr/lib64/libpq.so.3.1
If you use Red Hat's RPMs, you don't have this problem because they
provide PostgreSQL 7.4, which satisfies PHP dependency.
Here is a sample output from my RHEL 4 (x86_64) home box:
# rpm -e compat-postgresql-libs
error: Failed dependencies:
libpq.so.3()(64bit) is needed by (installed)
dovecot-0.99.11-2.EL4.1.x86_64
libpq.so.3()(64bit) is needed by (installed) perl-DBD-
Pg-1.31-6.x86_64
libpq.so.3()(64bit) is needed by (installed) php-
pgsql-4.3.9-3.9.x86_64
We could not document that well except questions in mailing lists and my
PostgreSQL blog, that's my mistake I believe.
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/