CLUSTER can change t_len

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.
--

Responses

Browse pgsql-hackers by date

  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?