Re: Why does VACUUM FULL bother locking pages?
От | Jonah H. Harris |
---|---|
Тема | Re: Why does VACUUM FULL bother locking pages? |
Дата | |
Msg-id | 36e682920509161341e624597@mail.gmail.com обсуждение исходный текст |
Ответ на | Why does VACUUM FULL bother locking pages? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Why does VACUUM FULL bother locking pages?
|
Список | pgsql-hackers |
Was it relcache related?
--
Respectfully,
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/
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
"Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente"
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Respectfully,
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: