DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=cmKoRzGc3mMOVrCGZK702ssCcy0fPaVpotaeLzgWsztKtNNit9hmoiGvI2sgnYza+0
	iEhMYYBAOlCIzzqp9l6fYiKsYIQeRdsBXzLI2KNK50uvBsrcD6wqe1V+R/NJ0QGQUDV9
	FVttWDhdVQmlAeBYkMNZrHcwixvW4K9V9bg0E=
Message-ID: <f7f6b4c70809171323s7a95e159ree839f20418c77d@mail.gmail.com>
Date: Wed, 17 Sep 2008 17:23:40 -0300
From: "Guido Barosio" <gbarosio@gmail.com>
To: "Scott Marlowe" <scott.marlowe@gmail.com>
Subject: Re: Heavy postgres process
Cc: "Kenneth Marshall" <ktm@rice.edu>,
 Vivek_Sharan <Vivek_Sharan@infosys.com>,
	"pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
In-Reply-To: <dcc563d10809171307g5bcf3d1au9214a82f5686f2f9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <5465CC59A600E2408FFBF84350B938345031E95B93@AUSMELMBX01.ad.infosys.com>
	<5465CC59A600E2408FFBF84350B9383450F4933C33@AUSMELMBX01.ad.infosys.com>
	<f7f6b4c70809160737l6e05616fgdc7c5e72ed19c582@mail.gmail.com>
	<5465CC59A600E2408FFBF84350B9383450F4933E11@AUSMELMBX01.ad.infosys.com>
	<f7f6b4c70809170608y1d2a7804p3af6b516ba83ab9@mail.gmail.com>
	<5465CC59A600E2408FFBF84350B9383450F4933E18@AUSMELMBX01.ad.infosys.com>
	<20080917183155.GA22468@it.is.rice.edu>
	<dcc563d10809171158m4e9bc06ao76e2361687400c1@mail.gmail.com>
	<f7f6b4c70809171243l72951796l94e3212f05829f00@mail.gmail.com>
	<dcc563d10809171307g5bcf3d1au9214a82f5686f2f9@mail.gmail.com>

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