Re: Why does VACUUM FULL bother locking pages?

I'm probably wrong, but I thought vacuum may invalidate stuff which
semi-required the cache to be flushed. :) I'll go take a look through
as-well but it's hard to imagine this being overlooked for so long.

Sorry Alvaro, I haven't gone out to look at vacuum in awhile so I ain't much
help.

On 9/16/05, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> 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(at)alvh(dot)no-ip(dot)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<http://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."
>

--
Respectfully,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/