Re: Why does VACUUM FULL bother locking pages? - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: Why does VACUUM FULL bother locking pages?
Date
Msg-id 36e682920509161341e624597@mail.gmail.com
Whole thread Raw
In response to Why does VACUUM FULL bother locking pages?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Why does VACUUM FULL bother locking pages?
List pgsql-hackers
Was it relcache related?

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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: statement_timeout logging
Next
From: Alvaro Herrera
Date:
Subject: Re: statement_timeout logging