Re: HOT line pointer bloat and PageRepairFragmentation

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: HOT line pointer bloat and PageRepairFragmentation
Дата
Msg-id 2e78013d0709130832t31244e79k9488a3e4eb00d64c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: HOT line pointer bloat and PageRepairFragmentation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: HOT line pointer bloat and PageRepairFragmentation  ("Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: HOT line pointer bloat and PageRepairFragmentation
Следующее
От: "Zeugswetter Andreas ADI SD"
Дата:
Сообщение: Re: HOT line pointer bloat and PageRepairFragmentation