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?
|
Список | 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 по дате отправления: