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@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 1:43 PM, Guido Barosio <gbarosio@gmail.com> 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
