Thread: Do you recommend 8.4 or 9.0 for basic usage?
Hello,
Could you give me your frank opinions about which of 8.4 or 9.0 you
recommend to ISVs who embed PostgreSQL?
We have used PostgreSQL 8.3 as a data repository of our software products.
Now we are developing the new versions of those existing products and a new
product. So, we are considering taking this opportunity to migrate to
PostgreSQL 8.4 or 9.0, because newer PostgreSQL versions will be supported
longer and offer features like visibility map and auto-sizing of free space
map that contribute to steadier operation.
We are considering which of 8.4 or 9.0 we should use. We value, in this
order, steady operation, software quality (less bugs), troubleshooting
functionality, and better compatibility for future versions (smoother
migration to 9.1 or later). We are just using basic simple read/write SQL
statements, online backup and recovery with continuous WAL archiving
(pg_start_backup/pg_stop_backup, etc.), so won't yet have a chance to
utilize most of 9.0's advanced functionality such as HS/SR, PL/pgSQL
enhancements, and so on. With that said, the following 9.0 features seem
interesting because they may help better operation:
* pg_upgrade
* speed up of VACUUM FULL
* buffer access counts of EXPLAIN, auto-explain, and pg_stat_statements
* logging of column values that violate unique key constraints
* pg_table_size/pg_index_size
We are wondering whether 9.0 is stable enough within the range of basic SQL
operations and backup/recovery so that you recommend taking advantage of
above features. Please let me hear your raw sense about 9.0 stableness as
developers who know the code well, after seeing many bug reports so far and
experiencing four minor releases. Do you recommend 8.4 or 9.0?
For reference, I collected the following data from the attached bug lists.
The number of regressions in 9.0 appear to be a bit high releative to
previous major releases. So I'm concerned that many new features might be
affecting the quality of features that have existed since before 9.0.
8.3 8.4 9.0
initial release date 2008-2-4 2009-7-1 2010-9-20
months between initial release and latest minor release 38 21 7
# of minor releases 15 8 4
total # of fixed bugs 314 227 81
# of fixed bugs newly made in each major release 107 82 33
# of fixed regressions 7 4 4
Regards
MauMau
Attachment
MauMau, > Could you give me your frank opinions about which of 8.4 or 9.0 you > recommend to ISVs who embed PostgreSQL? So, first of all, you posted this question to the wrong list. pgsql-general or pgsql-admin would have been more appropriatefor this question. That being said, I find your statistics on bug fixes interesting, so thank you for collecting them. However, at this time there have already been four update releases for 9.0, so you can be fairly assured that any major bugshave been fixed. 9.0 was definitely a higher patch release (and longer beta) than 8.4 specifically because of streamingreplication & hot standby. Those are major, complex features which offer the opportunity for issues which onlyoccur in multi-server configurations and are thus hard to test for. Our company has multiple ISV clients who are deploying products built on 9.0.X, and to date have had no special issues. As an ISV, though, you need to devise a plan whereby you can apply update releases to your client's machines if they areconnected to the internet. One of the primary reasons for update releases is closing security holes, which means thatyou need to have a way to upgrade your customers. Some of the biggest issues we've seen in our clients is that an inabilityto apply in-the-field updates causing customers to experience bugs which have long been fixed in PostgreSQL releases. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco
Josh, From: "Joshua Berkus" <josh@agliodbs.com> >> Could you give me your frank opinions about which of 8.4 or 9.0 you >> recommend to ISVs who embed PostgreSQL? > > So, first of all, you posted this question to the wrong list. > pgsql-general or pgsql-admin would have been more appropriate for this > question. > However, at this time there have already been four update releases for > 9.0, so you can be fairly assured that any major bugs have been fixed. > 9.0 was definitely a higher patch release (and longer beta) than 8.4 > specifically because of streaming replication & hot standby. Those are > major, complex features which offer the opportunity for issues which only > occur in multi-server configurations and are thus hard to test for. > > Our company has multiple ISV clients who are deploying products built on > 9.0.X, and to date have had no special issues. > > As an ISV, though, you need to devise a plan whereby you can apply update > releases to your client's machines if they are connected to the internet. > One of the primary reasons for update releases is closing security holes, > which means that you need to have a way to upgrade your customers. Some > of the biggest issues we've seen in our clients is that an inability to > apply in-the-field updates causing customers to experience bugs which have > long been fixed in PostgreSQL releases. Thank you very much for offering your experience and advice, I'd like to share your voice with my boss. And I'm sorry for posting to the wrong list. Yes, I was torn between pgsql-hackers and pgsql-general. I didn't want to unintentionally give misconception about 9.0 quality to general users, so I kept the mail here in the end. Regards, MauMau
On Sun, May 22, 2011 at 12:32:48PM -0500, Josh Berkus wrote: > MauMau, > > > Could you give me your frank opinions about which of 8.4 or 9.0 > > you recommend to ISVs who embed PostgreSQL? > As an ISV, though, you need to devise a plan whereby you can apply > update releases to your client's machines if they are connected to > the internet. You need such a plan whether the clients' machines are connected to the internet or not because access control[1] is not the only place where your system may turn out to have bugs. The only case where you will not need such a plan is for a disposable system, i.e. where the decision tree for "there's a bug" has one branch, which is "replace the system." Cheers, David. [1] Please try hard not to confuse access control with security. Access control has been, is, and will continue to be used by attackers to damage systems from ones as small as chat rooms all the way up to governments and economies. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate