Skip site navigation (1) Skip section navigation (2)

Re: column size too large, is this a bug?

From: Andrew Rawnsley <ronz(at)ravensfield(dot)com>
To: Qing Zhao <qzhao(at)quotefx(dot)net>
Cc: josh(at)agliodbs(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: column size too large, is this a bug?
Date: 2004-03-26 18:15:21
Message-ID: 8B3A05B5-7F51-11D8-93F3-000393A47FCC@ravensfield.com (view raw or flat)
Thread:
Lists: pgsql-performance
I used to use the connect-by patch, but have since rewritten everything 
to use a nested set model. I was
having problems that, while not immediately traceable back to the 
patch, showed up when I started
using it and went away when I stopped (strange locking behavior, 
crashing with vacuum full, problems after
dropping columns) . Plus the annoyance of maintaining a non-stock build 
across numerous installations
exceeded its benefits. Relying on it for a business critical situation 
became too much of a risk.



On Mar 26, 2004, at 12:29 PM, Qing Zhao wrote:

> Thanks a lot!  We were migrating to Postgres from Oracle and
> every now and then, we ran into something that we do not
> understand completely and  it is a learning process for us.
>
> Your responses have made it much clear for us. BTW, do you
> think that it's better for us just to rewrite everything so we don't
> need to use the patch at all? Why do others still use it?
>
> Thanks!
>
> Qing
> On Mar 25, 2004, at 6:04 PM, Tom Lane wrote:
>
>> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>>> Oh, good eye ... it's that infamous CONNECT BY patch again, without 
>>>> doubt.
>>
>>> Hey, who does this patch?   What's wrong wiith it?
>>
>> I'm just venting my annoyance at people expecting us to support
>> hacked-up versions, especially without telling us they're hacked-up.
>> This is the third or fourth trouble report I can recall that was
>> eventually traced to that patch (after considerable effort).
>>
>> Anyway, my guess for the immediate problem is incorrect installation 
>> of
>> the patch, viz not doing a complete "make clean" and rebuild after
>> patching.  The patch changes the Query struct which is referenced in
>> many more files than are actually modified by the patch, and so if you
>> didn't build with --enable-depend then a simple "make" will leave you
>> with a patchwork of files that have different ideas about the field
>> offsets in Query.  I'm a bit surprised it doesn't just dump core...
>>
>> (That's not directly the fault of the patch, though, except to the
>> extent that it can be blamed for coming without adequate installation
>> instructions.  What is directly the fault of the patch is that it
>> doesn't force an initdb by changing catversion.  The prior trouble
>> reports had to do with views not working because their stored rules 
>> were
>> incompatible with the patched backend.  We should not have had to deal
>> with that, and neither should those users.)
>>
>> Theory B, of course, is that this is an actual bug in the patch and 
>> not
>> just incorrect installation.  I'm not interested enough to investigate
>> though.
>>
>> 			regards, tom lane
>>
>
>
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2004-03-26 21:53:40
Subject: Re: postgres eating CPU on HP9000
Previous:From: Josh BerkusDate: 2004-03-26 18:01:47
Subject: Re: column size too large, is this a bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group