RE: BUG #15067: Documentation or behaviour bug with autovacuum thresholds?

> > I think there is a documentation bug in the Autovacuum section:
> No, there isn't.
> "exceed" means "greater than". Hence, documentation is accurate.
> > I think there is a documentation bug in the Autovacuum section:
> No, there isn't.
> "exceed" means "greater than". Hence, documentation is accurate.

Hi Euler,

I had considered that, but if you do *exactly* the same number of updates as the threshold... wait... and then do a single update, it vacuums a single row, not threshold+1. In my example:

1) autovacuum_vacuum_scale_factor = 0
2) autovacuum_vacuum_threshold = 500
3) Update 500 rows of a 1,000 row table
4) Wait 30 seconds
5) Update 1 row
6) NOTE: "tuples: 1 removed" in the postgres.log, not "tuples: 501 removed".

< 2018-02-14 15:20:08.512 GMT > LOG: automatic vacuum of table "postgres.public.autovacuum_threshold_test": index scans: 0
pages: 0 removed, 7 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 1 removed, 1000 remain, 0 are dead but not yet removable

There are two potential issues with that:

1) The autovacuum_vacuum_threshold is 500, so it should never vacuum anything less... especially not a single tuple.
(Is that a bug in autovacuum, triggering on less than the threshold?)

2) Nowhere does it ever mention "tuples: 500 removed", so what happened to the originally updated 500 tuples?
- Did they get vacuumed silently?
(Is that a bug in autovacuum, where it doesn't report correctly?)
- Did they skip being vacuumed?
(Are these rows being lost forever, adding to bloat?)

In short, what happened to the initial autovacuum_vacuum_threshold (500) updates, and why did autovacuum run on a single row?

Cheers,
Greg.