Skip site navigation (1) Skip section navigation (2)

Re: Autovacuum versus rolled-back transactions

From: Matthew O'Connor <matthew(at)zeut(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Autovacuum versus rolled-back transactions
Date: 2007-05-27 04:44:15
Message-ID: 46590C9F.2070804@zeut.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> This means that a table could easily be full of dead tuples from failed
> transactions, and yet autovacuum won't do a thing because it doesn't
> know there are any.  Perhaps this explains some of the reports we've
> heard of tables bloating despite having autovac on.

I think this is only a problem for failed inserts as failed updates will 
be accounted for correctly by autovac and as you said, failed deletes 
really do nothing.  So is there a way for rollback to just add the 
number of rolled back inserts to the n_tup_del counter?  Then we would 
be ok, no?

> I think it's fairly obvious how n_live_tup and n_dead_tup ought to
> change in response to a failed xact, but maybe not so obvious for the
> other counters.  I suggest that the scan/fetch counters (seq_scan,
> seq_tup_read, idx_scan, idx_tup_fetch) as well as all the block I/O
> counters should increment the same for committed and failed xacts,
> since they are meant to count work done regardless of whether the work
> was in vain.  I am much less sure how we want n_tup_ins, n_tup_upd,
> n_tup_del to act though.  Should they be advanced "as normal" by a
> failed xact?  That's what the code is doing now, and if you think they
> are counters for work done, it's not so unreasonable.

I think autovac only considers n_tup_(upd|ins|del) so while it might be 
correct to fix those other counters, I don't know that they are must fix 
items.



In response to

pgsql-hackers by date

Next:From: Jeremy DrakeDate: 2007-05-27 05:08:01
Subject: buildfarm failures after pgstat patch
Previous:From: Tom LaneDate: 2007-05-27 03:59:03
Subject: Re: Error correction for n_dead_tuples

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group