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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to