Re: Quick idea for reducing VACUUM contention
От
Decibel!
Тема
Re: Quick idea for reducing VACUUM contention
Дата
Msg-id
8EE9969E-E9EF-4C7F-938E-7B48C8392DBB@decibel.org
Ответ на
Re: Quick idea for reducing VACUUM contention (Alvaro Herrera)
Список
Дерево обсуждения
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 по дате отправления