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?
> 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
>>> 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
>> 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
>> 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
>> just incorrect installation. I'm not interested enough to investigate
>> regards, tom lane
> ---------------------------(end of
> TIP 4: Don't 'kill -9' the postmaster
The Ravensfield Digital Resource Group, Ltd.
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2004-03-26 21:53:40|
|Subject: Re: postgres eating CPU on HP9000 |
|Previous:||From: Josh Berkus||Date: 2004-03-26 18:01:47|
|Subject: Re: column size too large, is this a bug?|