On Tue, Nov 9, 2010 at 12:44 PM, Jeff Davis <pg...@j-davis.com> wrote:
> See case below. After the item length gets changed, then when reading
> the tuple later you get a t_len that includes padding.

We can easily find it with pageinspect:

\i pageinspect.sql
create table foo(i int4);
insert into foo values(1);
SELECT lp, lp_len FROM heap_page_items(get_raw_page('foo', 0));
 lp | lp_len
----+--------
  1 |     28
VACUUM FULL foo;
SELECT lp, lp_len FROM heap_page_items(get_raw_page('foo', 0));
 lp | lp_len
----+--------
  1 |     32

> We should document in a comment that t_len can mean multiple things. Or,
> we should fix raw_heap_insert() to be consistent with the rest of the
> code, which doesn't MAXALIGN the t_len.

We have a comment /* be conservative */ in the function, but I'm not sure
we actually need the MAXALIGN. However, there would be almost no benefits
to keep t_len in small value because we often treat memory in MAXALIGN unit.

diff --git a/src/backend/access/heap/rewriteheap.c
b/src/backend/access/heap/rewriteheap.c
index 0bd1865..0ed94ef 100644
*** a/src/backend/access/heap/rewriteheap.c
--- b/src/backend/access/heap/rewriteheap.c
*************** raw_heap_insert(RewriteState state, Heap
*** 586,592 ****
    else
        heaptup = tup;

!   len = MAXALIGN(heaptup->t_len);     /* be conservative */

    /*
     * If we're gonna fail for oversize tuple, do it right away
--- 586,592 ----
    else
        heaptup = tup;

!   len = heaptup->t_len;

    /*
     * If we're gonna fail for oversize tuple, do it right away


-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to