Where can I buy that t-shirt? :) Hmm, you are right. My intention was to explain that the case for a 7.4.21 (wich AFAIK is the latest one of the 7.4 series) is the same as for the v8 series of the server. 7.4.8 seems to be the latest one before a dump & restore would be a good idea. That was my point. Apologies for the noise! Gb.- On Wed, Sep 17, 2008 at 5:07 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Wed, Sep 17, 2008 at 1:43 PM, Guido Barosio <gbarosio@xxxxxxxxx> wrote: >> Getting to the latest 7.4 server involves the same as going to the >> latest 8.x server, AFAIK, if we take in consideration that 7.4.8 >> requires a dump & restore (meaning downtime). > > 7.4.7 to 7.4.8 does NOT require a complete dump and restore. Been > there, done it and got the tshirt. There's a minor fix in the > catalogs that you can get by a single SQL command. > >> I would rather go after the latest 8.x server >> >> 2 cents. > > Me too. But the update to 7.4.21 or whatever the latest version is > does NOT require a dump reload, and unless you need that one line sql > fix, you don't even have to do that. > > I quote the 7.4.8 release notes: > > A dump/restore is not required for those running 7.4.X. However, it is > one possible way of handling two significant security problems that > have been found in the initial contents of 7.4.X system catalogs. A > dump/initdb/reload sequence using 7.4.8's initdb will automatically > correct these problems. > > and further down > > If you wish not to do an initdb, perform the following procedures > instead. As the database superuser, do: > > BEGIN; > UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype > WHERE pronamespace = 11 AND pronargs = 5 > AND proargtypes[2] = 'cstring'::regtype; > -- The command should report having updated 90 rows; > -- if not, rollback and investigate instead of committing! > COMMIT; > > Next, if you have installed contrib/tsearch2, do: > > and so on. > >> (It seems that Vivek works for Infosys, and that may explain the >> reason for an Oracle migration in the future. They are prolly plenty >> of Oracle DBA's working there, cheaper and reusable for sure if you >> think that often the kind of clients they handle are already >> oracle'ized ) > > especially if you can piggy back on someone else's oracle server > that's already running. > -- http://www.linkedin.com/in/gbarosio
