Re: Quick idea for reducing VACUUM contention

Поиск
Список
Период
Сортировка
Искать
От
Decibel!
Тема
Re: Quick idea for reducing VACUUM contention
Дата
Msg-id
8EE9969E-E9EF-4C7F-938E-7B48C8392DBB@decibel.org
Ответ на
Список
Дерево обсуждения
Quick idea for reducing VACUUM contention "Simon Riggs" <simon@2ndquadrant.com>
Re: Quick idea for reducing VACUUM contention ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Decibel! <decibel@decibel.org>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Jim Nasby <decibel@decibel.org>
Re: Quick idea for reducing VACUUM contention Alvaro Herrera <alvherre@commandprompt.com>
Re: Quick idea for reducing VACUUM contention Decibel! <decibel@decibel.org>
On Jul 30, 2007, at 8:00 PM, Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
>> Alvaro Herrera  wrote:
>>>> I think we might need additional "freezing-xmax" operations to  
>>>> avoid
>>>> XID-wraparound in the first path of vacuum, though it hardly  
>>>> occurs.
>>>
>>> I'm not sure I follow.  Can you elaborate?  Do you mean storing a
>>> separate relfrozenxmax for each table or something like that?
>>
>> We need to work around wraparound of xmax in dead tuples. If we  
>> miss to
>> vacuum them and XID is wrapped, we cannot remove them until the next
>> XID-wraparound, because we treat them to be deleted in the *future*.
>
> Oh, but this should not be a problem, because a tuple is either frozen
> or removed completely -- xmax cannot precede xmin.

What if it's frozen, then deleted, and then we wrap on xmax? Wouldn't  
that make the tuple re-appear?
-- 
Decibel!, aka Jim Nasby                        decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)



В списке pgsql-hackers по дате отправления
От: Alvaro Herrera
Дата:
Сообщение: Re: [GENERAL] ascii() for utf8
От: Alvaro Herrera
Дата:
FAQ