From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CLUSTER can change t_len |
Date: | 2010-11-09 09:11:59 |
Message-ID: | AANLkTi=NyAK9S8wi2X5uUwzJ2znvt3ajsfVRKun4XiYD@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 9, 2010 at 12:44 PM, Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2010-11-09 09:38:33 | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Previous Message | David E. Wheeler | 2010-11-09 08:19:23 | Re: Query Plan Columns |