On 22.07.2012 14:09, Matthew Woodcraft wrote:
Does that mean they will implement security fixes and general bug fixes
in their version of PostgreSQL?

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Hi Mathew,

On 7/22/2012 5:09 AM, Matthew Woodcraft wrote:
"Easy" doesn't mean that it doesn't "take time". As with most
projects, *that* is usually the limiting factor (only so many
hours in a day!)

I've found it is reasonably painless to move (forward) along the
pg upgrade path. It's a bit of a chore dumping and reloading
an entire database (depending on size and secondary storage you have
available to you) but (so far), so far, the process seems to go without
a hitch.

OTOH, I always build from sources so if you're stuck waiting for
a prepackaged binary, your mileage *will* vary :-/

Don Y wrote on 22.07.2012 19:30:
Since 8.4 and pg_upgrade, upgrades have become much less painful.

Hi Hans,

On 7/22/2012 11:24 AM, Hans Castorp wrote:
I'm not sure I "trust" pg_upgrade, entirely, when it comes to
the "universe of potential databases/sets" it might encounter.

E.g., I have several custom base types that I use. So, as part of
each upgrade, I dig through the sources to see what, if anything,
in the "type interface" may have changed to be sure my existing
types will continue to work when imported to the new implementation.

I find the dump + reload option is the most reassuring one (to me)
as I *know* that my code will rexamine the dumped data as it is
being reloaded. I don't have to worry that some subtle change
will bite me *after* it's in place (without a way of returning to
the known, working configuration).

And, of course, pg_upgrade doesn't help you *build* the new
binaries (which Matthew might require)

Robert Klemme <shortcutter (AT) googlemail (DOT) com> wrote:
I expect it's something along the lines of security fixes and dataloss
bug fixes, and I think it's unlikely there'll be many of the latter
turning up now.

I'm not speaking from experience; I use Debian and maybe there's some
fine print I haven't seen.

But certainly Red Hat employ sufficient expertese, and RHEL5 isn't even
out of the highest-level-support part of its 'lifecycle' yet.

-M-

On 2012-07-22, Graham Murray <newspost (AT) gmurray (DOT) org.uk> wrote:
I'll upgrade as soon as redhat 5 upgrades. It is a work requirement
that I track redhat 5. Well, I could track redhat 6, but I don't
really want to upgrade my entire cluster at this point.