Re: HOT line pointer bloat and PageRepairFragmentation

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: HOT line pointer bloat and PageRepairFragmentation
Date: 2007-09-13 15:32:34
Message-ID: 2e78013d0709130832t31244e79k9488a3e4eb00d64c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/13/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas ADI SD 2007-09-13 15:43:13 Re: HOT line pointer bloat and PageRepairFragmentation
Previous Message Tom Lane 2007-09-13 14:42:28 Re: HOT line pointer bloat and PageRepairFragmentation