Re: Why does VACUUM FULL bother locking pages?

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Why does VACUUM FULL bother locking pages?
Дата
Msg-id 20050916210734.GB9069@surnet.cl
обсуждение исходный текст
Ответ на Re: Why does VACUUM FULL bother locking pages?  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Ответы Re: Why does VACUUM FULL bother locking pages?  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Список pgsql-hackers
On Fri, Sep 16, 2005 at 04:41:39PM -0400, Jonah H. Harris wrote:
> Was it relcache related?

I don't see how -- any user of a relcache entry needs to heap_open() or
relation_open() the table and acquire an appropiate lock.  Any such call
would block because of the lock that VACUUM FULL acquires on the relation.

> On 9/16/05, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > 
> > Hackers,
> > 
> > I'm reading the vacuum code and I just noticed that the routines
> > move_plain_tuple and move_chain_tuple expect the dest and source blocks
> > to be locked, and unlock them at exit. The only caller of both is
> > repair_frag, whose only caller in turn is full_vacuum_rel. Same thing
> > for update_hint_bits.
> > 
> > So, the only callers of both has already acquired appropiate locks at
> > the relation level -- nobody is going to be modifying the blocks while
> > they proceed. So why bother locking the pages at all? Is there a
> > reason or is this an historical accident?

-- 
Alvaro Herrera -- Valdivia, Chile         Architect, www.EnterpriseDB.com
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: statement_timeout logging
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: statement logging / extended query protocol issues