FAQ
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

Search Discussions

  • Joshua Berkus at May 22, 2011 at 5:32 pm
    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 appropriate for 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 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.

    --
    Josh Berkus
    PostgreSQL Experts Inc.
    http://pgexperts.com
    San Francisco
  • MauMau at May 22, 2011 at 9:01 pm
    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
  • David Fetter at May 23, 2011 at 3:03 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 22, '11 at 10:18a
activeMay 23, '11 at 3:03p
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase