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