From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Quick idea for reducing VACUUM contention |
Date: | 2007-07-31 15:09:59 |
Message-ID: | 8EE9969E-E9EF-4C7F-938E-7B48C8392DBB@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 30, 2007, at 8:00 PM, Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-07-31 15:25:42 | Re: Quick idea for reducing VACUUM contention |
Previous Message | Alvaro Herrera | 2007-07-31 13:55:31 | Re: [GENERAL] ascii() for utf8 |