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

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