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-26 15:38:08 |
Message-ID: | 45BA2060.7090406@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:
>> 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.
>
> Hm, mis-counting the positions of itempointers maybe?
Found it:
/* Count up total space in data items without actually scanning 'em */
dataitemtotal = rightspace - (int) PageGetFreeSpace(page);
This is 4 bytes off, because PageGetFreeSpace subtracts
sizeof(ItemIdData) from the actual free space on page. We could do
dataitemtotal = rightspace - ((int) PageGetFreeSpace(page)
+sizeof(ItemIdData));
but that again would be 4 bytes off in the other direction if there's 0
bytes left on the page :(.
IMHO the right fix is to modify PageGetFreeSpace not to do the
subtraction, it's a hack anyway, but that means we have to go through
and fix every caller of it. Or we can add a new PageGetReallyFreeSpace
function and keep the old one for compatibility. What do we want?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-26 15:39:59 | Re: Implied Functional index use (redux) |
Previous Message | Tom Lane | 2007-01-26 15:31:08 | Re: BUG #2917: spi_prepare doesn't accept typename aliases |