Re: HOT line pointer bloat and PageRepairFragmentation - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: HOT line pointer bloat and PageRepairFragmentation
Date
Msg-id 2e78013d0709130832t31244e79k9488a3e4eb00d64c@mail.gmail.com
Whole thread Raw
In response to Re: HOT line pointer bloat and PageRepairFragmentation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HOT line pointer bloat and PageRepairFragmentation
List pgsql-hackers


On 9/13/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:


The difficulty with this is having to be 100% confident that noplace in
the system tries to dereference a TID without checking that the line
number (offset) is within range.  At one time that was demonstrably
not so.  I think we've cleaned up most if not all such places, but
I wouldn't want to swear to it.


If there are such places, aren't we already in problem ? An unused
line pointer can be reused for unrelated tuple. Dereferencing the TID
can cause data corruption, isn't it ? If you want, I can do
a quick search for all callers of PageGetItemId and confirm that
the offset is checked and add any missing checks.

In normal circumstances, line pointer bloat should not occur. But in
some typical cases it may cause unrepairable damage. For example:

CREATE TABLE test (a int, b char(200));
CREATE UNIQUE INDEX testindx ON test(a);
INSERT INTO test VALUES (1, 'foo');

Now, if we repeatedly update the tuple so that each update is a
COLD update, we would bloat the page with redirect-dead line pointers.

Any other idea to recover from this  ?

Thanks,
Pavan


--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HOT line pointer bloat and PageRepairFragmentation
Next
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: Re: HOT line pointer bloat and PageRepairFragmentation