Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Looking again, PageRepairFragmentation is called on a copy of the page,
> not on the page itself, so this is not a problem. The page is only
> modified to exchange old Xids for FrozenTransactionId, or to set some
> hint bits, so this really shouldn't be
On Thu, 2005-09-22 at 10:36 -0400, Alvaro Herrera wrote:
> Seems like a bug to me.
Well done. This wins the award for best bug found during beta; shame it
wasn't 8.0 beta!
Just as well we recommend only doing VACUUM FULL when the system is
quiet
Best Regards, Simon Riggs
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Oh, certainly! In this case, may I point out that scan_heap() does not
> bother locking pages, mentioning that "we assume that holding exclusive
> lock on the relation will keep other backends from looking at the page".
> In particular, it calls PageRep
On Thu, Sep 22, 2005 at 10:36:41AM -0400, Alvaro Herrera wrote:
> On Fri, Sep 16, 2005 at 11:50:21PM -0700, Simon Riggs wrote:
> > > Alvaro Herrera wrote
> > > The only caller of both is
> > > repair_frag, whose only caller in turn is full_vacuum_rel.
> >
> > ...bgwriter still needs to access bloc
On Fri, Sep 16, 2005 at 11:50:21PM -0700, Simon Riggs wrote:
> > Alvaro Herrera wrote
> > The only caller of both is
> > repair_frag, whose only caller in turn is full_vacuum_rel.
>
> ...bgwriter still needs to access blocks. The WAL system relies on the
> locking behaviour for recoverability, see
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> 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 wrote
> The only caller of both is
> repair_frag, whose only caller in turn is full_vacuum_rel.
...bgwriter still needs to access blocks. The WAL system relies on the
locking behaviour for recoverability, see comments in LockBuffer() and
SyncOneBuffer().
...I do think there's lot
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
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
Was it relcache related?On 9/16/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Hackers,I'm reading the vacuum code and I just noticed that the routinesmove_plain_tuple and move_chain_tuple expect the dest and source blocksto be locked, and unlock them at exit. The only caller of both is
repair_frag
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_hin
11 matches
Mail list logo
