From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: crash on 8.2 and cvshead - failed to add item to the |
Date: | 2007-01-25 17:15:57 |
Message-ID: | 45B8E5CD.8080409@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> Hmm. There seems to be something wrong in the free space calculation in
>> the algorithm for choosing the right split location. I'll dig deeper,
>> unless someone beats me to it..
>
> I seem to recall that that part of the code was changed recently, so you
> might try looking at the CVS history for hints. This is probably
> recently introduced, else we'd have seen it reported before :-(
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered. With a
50% or 67% target for splitting, there is a lot more wiggle room.
To see what's going on, I added some logs to the split code to print out
the free space on both halves as calculated by findsplitloc, and the
actual free space on the pages after split. I'm seeing a discrepancy of
4 bytes on the right half; actual space free on right page after split
is 4 bytes less than anticipated. That's on every split, not just in
some corner cases. That's not a big deal, but I'll take a closer look
tomorrow to see what's missing from the calculations.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-25 17:22:48 | Re: crash on 8.2 and cvshead - failed to add item to the |
Previous Message | Gregory Stark | 2007-01-25 17:12:12 | Re: Recursive Queries |