I think you are on to something here. Clearly dump/reload works, and testing pg_upgrade is time-consuming, so people aren't as inclined to jump into testing. It isn't quite like testing a bugfix or new feature.
--------------------------------------------------------------------------- Thomas O'Connell wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Bruce Momjian) wrote: > > > Is pg_upgrade too hard to run? Is no one really interested in it? > > As an end-user, I'm very interested in pg_upgrade, but I think it's kind > of a chicken and egg problem. > > Without much of a guarantee that it's fail-safe, I'm not inclined to > test it. As kind of a hamstrung DBA, I don't have a lot of time to do > mock-upgrading of my postgres installations. I would imagine there are > plenty of DBAs in the user community in this position: wanting a good > upgrade utility but not having the time/inclination to do testing on > what is available. > > For commercial products, QA is usually internal. One of the slight > drawbacks to the free software community is that more of the burden of > QA is placed on the at-large community of users. > > All this being said, if an outline were posted of what steps to take to > test pg_upgrade and ensure that everything were working properly, I'd be > more inclined to take the plunge. As it is, I'd have to do a fair amount > of research on my own to make sure nothing broke. And that is the step I > don't have time for. > > -tfo > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster