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=QZ+jnkbThtUEru9R3SLr9rsP7bBRDJRVbfTRdvUmrhuR9Et4mKAW5Na5zyC0ixNzze
	6cti6dxIfnPdXZn1qmH7mr1iJCYUYn7p8i6ZvPBtNzubmM9Z+HfDPNGibhX6inkmOPfK
	bnz0ArSAhKHC04cKa8es/pNVyRjdN7WzyeT2o=
Message-ID: <dcc563d10812301051s7ca6b391q132a5194820d8269@mail.gmail.com>
Date: Tue, 30 Dec 2008 11:51:50 -0700
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: "Bhujbal, Santosh" <sbhujbal@starentnetworks.com>
Subject: Re: postgres block_size problem
Cc: pgsql-admin@postgresql.org
In-Reply-To: 
 <3BD53621E5C8E54594130AF5459379EE08D80D41@exchindia4.starentnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <3BD53621E5C8E54594130AF5459379EE08D80D41@exchindia4.starentnetworks.com>

On Tue, Dec 30, 2008 at 5:28 AM, Bhujbal, Santosh
<sbhujbal@starentnetworks.com> wrote:
> Hi All,
>
> We were getting the following error on executing a COPY command on
> postgres8.2.0.

First and foremost, you need to run the latest version of 8.2, not
8.2.0.  .0 releases of postgresql tend to have the most bugs.  You're
missing two years of updates by running 8.2.0.  Who knows what bugs
you may be running into by running 8.2.0

While you're at it, you might want to look at upgrading to 8.3.5,
which has quite a few enhancements over 8.2.x  But it's not that big
of a deal.  8.2 is a good performer overall.

> SQL execution failed, Internal error. SQL Statement: (COPY command failed
> with error: ERROR:  row is too big: size 8200, maximum size 8136)

Hmmm.  What exactly are you trying to insert into what?  Normally when
you see something like this it's an index on a text field that causes
this type of problem.  But I'm not sure what's going on here.
Normally postgresql will move large things out of line into a toast
table.  Are you running a non-standard storage parameter?

> So, in order to fix the error we tried increasing the block size to 16k and
> recompiled the postgres library.

If you can get away with NOT using >8k blocks, do so.  The code base
is no where near as well tested with block sizes over 8k as it is with
8k blocks, the default.

> The problem at hand was resolved with the
> new postgres library and we were now able to populate data for the mentioned
> query successfully. However, this experiment fails when we tried to run the
> new postgres on data directory generated with 8k block size which is likely
> to occur during an upgrade with postgres log showing the following error:

Yeah, running a non-standard block size is only advised if you're
willing to go to the extra effort each time to build a new package by
hand.  And require that of any users who use your application to do
the same, or run a custom package you provide.

> What could be the possible solution to this?

Can you explain in more detail exactly what you're doing to cause the
problem?  A short test case you can post would be most helpful.