Peter Eisentraut writes:
> On Monday 06 April 2009 04:29:02 Tom Lane wrote:
>> The only question I have is whether we want this nag message or not:
> If it is supposed to be DEBUG1, would you mind if I convert it to an elog so
> it doesn't appear in the translation roster?
Okay with me. You co
On Monday 06 April 2009 04:29:02 Tom Lane wrote:
> The only question I have is whether we want this nag message or not:
>
> ! ereport(LOG,
> ! (errcode(ERRCODE_INTERNAL_ERROR),
> ! errmsg("Picksplit method for %d column of index \"%s\"
> failed", !
This looks good to me. I tested it to the extent of verifying that
either patch individually would prevent the originally-reported failure.
I'd be inclined to keep it but reduce it to level DEBUG1 or so.
Committed in HEAD, 8.3 and 8.2. Previous versions need to be patched too but
codebase is d
Teodor Sigaev writes:
>> I don't like throwing an error there; I wish there were a way for the
>> generic code to apply the fallbackSplit code instead. I see that
>> in this particular formulation it's dependent on the datatype ---
>> can we get around that, by having it invoke the union method?
I don't like throwing an error there; I wish there were a way for the
generic code to apply the fallbackSplit code instead. I see that
in this particular formulation it's dependent on the datatype ---
can we get around that, by having it invoke the union method?
Done. rtree.patch.gz contains pa
Teodor Sigaev writes:
>> Here is a test case that crashes even with the patch:
> I was too optimistic :(
> Attached patch contains:
> - changes in R-tree picksplit methods. Now it checks bad ratio and if so then
>use simple split: one half of entries to one page, and another part - to
>a
Here is a test case that crashes even with the patch:
I was too optimistic :(
Attached patch contains:
- changes in R-tree picksplit methods. Now it checks bad ratio and if so then
use simple split: one half of entries to one page, and another part - to
another page.
- protection from buggy
Andrew Gierth writes:
> I think that not only does there need to be another IS_BADRATIO check,
> but also there needs to be some sort of backstop in gistSplit or
> gistUserPicksplit to either recover or (as a last resort) error out
> cleanly rather than crash the entire db in cases that would resu
> "Teodor" == Teodor Sigaev writes:
>> even further. And what confidence do you have that this change
>> eliminates all forms of the problem, anyway?
Teodor> Yes, I think. Because that part of code ( if (IS_BADRATIO)
Teodor> {...} ) is a corner case itself. In example from Andrew, all
> "Tom" == Tom Lane writes:
> Teodor Sigaev writes:
>> Look at the patch, it fixes the problem by comparing for equality
>> by FPeq() macros which is used everywhere in geometry calculation.
Tom> Ick. FPeq() is a crock; I'd like to see us get rid of it, not
Tom> spread it even further
even further. And what confidence do you have that this change
eliminates all forms of the problem, anyway?
Yes, I think. Because that part of code ( if (IS_BADRATIO) {...} ) is a corner
case itself. In example from Andrew, all boxes are placed to one page because of
floating-point rounding.
Teodor Sigaev writes:
> Look at the patch, it fixes the problem by comparing for equality by FPeq()
> macros which is used everywhere in geometry calculation.
Ick. FPeq() is a crock; I'd like to see us get rid of it, not spread it
even further. And what confidence do you have that this change
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then it tries to split the data
again based on the positions of the box centers. But there's a problem
here with floating-point rounding; it's possible for the average of N
Look at the patc
> "Martijn" == Martijn van Oosterhout writes:
>> The nature of the problem is this: if gist_box_picksplit doesn't
>> find a good disposition on the first try, then it tries to split
>> the data again based on the positions of the box centers. But
>> there's a problem here with floating-po
On Thu, Mar 26, 2009 at 02:39:05PM +, Andrew Gierth wrote:
> A user on IRC reported a crash (backend segfault) in GiST insertion
> (in 8.3.5 but I can reproduce this in today's HEAD) that turns out
> to be due to misbehaviour of gist_box_picksplit.
>
> The nature of the problem is this: if gis
On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth
wrote:
> A user on IRC reported a crash (backend segfault) in GiST insertion
> (in 8.3.5 but I can reproduce this in today's HEAD) that turns out
> to be due to misbehaviour of gist_box_picksplit.
>
> The nature of the problem is this: if gist_box_pic
On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth
wrote:
> A user on IRC reported a crash (backend segfault) in GiST insertion
> (in 8.3.5 but I can reproduce this in today's HEAD) that turns out
> to be due to misbehaviour of gist_box_picksplit.
>
Andrew, thank you for the test case and report.
p.
A user on IRC reported a crash (backend segfault) in GiST insertion
(in 8.3.5 but I can reproduce this in today's HEAD) that turns out
to be due to misbehaviour of gist_box_picksplit.
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then it
18 matches
Mail list logo
