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.
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
