From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | CLUSTER can change t_len |
Date: | 2010-11-09 03:44:45 |
Message-ID: | 1289274285.754.8.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I don't think that this is a bug exactly, but it seems inconsistent.
See case below. After the item length gets changed, then when reading
the tuple later you get a t_len that includes padding.
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.
Regards,
Jeff Davis
create table foo(i int4 unique);
insert into foo values(1);
insert into foo values(2);
checkpoint;
select relfilenode from pg_class where relname = 'foo';
relfilenode
-------------
16413
(1 row)
--
-- Look at on-disk item lengths, which are 28 (0x38 >> 1)
-- on my machine
--
cluster foo using foo_i_key;
select relfilenode from pg_class where relname = 'foo';
relfilenode
-------------
16418
(1 row)
checkpoint;
--
-- Now look again. They are 32 (0x40 >> 1) on my machine.
--
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-09 04:03:06 | Re: Avoid memory leaks during ANALYZE's compute_index_stats() ? |
Previous Message | Vaibhav Kaushal | 2010-11-09 02:55:15 | Fwd: Which file does the SELECT? |