Skip site navigation (1) Skip section navigation (2)

Re: Quick idea for reducing VACUUM contention

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Decibel! <decibel(at)decibel(dot)org>
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:25:42
Message-ID: 20070731152542.GG5103@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Decibel! wrote:
> 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?

That cannot happen, because the next vacuum will remove the tuple if the
Xmax is committed.  If the deleting transaction aborts, then vacuum will
set Xmax to Invalid (see heap_freeze_tuple in heapam.c).

One potential problem you would see is if the deleting transaction marks
it deleted and then not commit for 2 billion transactions, thus vacuum
is not able to remove it because it shows up as delete-in-progress.
However there are plenty other problems you would hit in that case
(autovacuum starting to misbehave being the first you would probably
notice).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-07-31 15:34:15
Subject: Re: Reducing Transaction Start/End Contention
Previous:From: Decibel!Date: 2007-07-31 15:09:59
Subject: Re: Quick idea for reducing VACUUM contention

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group