On Sun, May 3, 2015 at 7:49 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Restricting ourselves to selecting tables to vacuum using their
> relminmxid alone makes this patch small since autovacuum already works
> that way. We *could* introduce code that would be able to spread out
> the work of vacuuming tables that happen to have identical or very
> close relminmxid (say by introducing some non-determinism or doing
> something weird based on hashing table oids and the time to explicitly
> spread the start of processing over time, or <your idea here>), but I
> didn't want to propose anything too big/complicated/clever/stupid and
> I suspect that the relminmxid values will tend to diverge over time
> (but I could be wrong about that, if they all start at 1 and then move
> forward in lockstep over long periods of time then what I propose is
> not good enough... let's see if we can find out).
So, the problem of everything moving in lockstep is one we already
have. It's actually a serious operational problem for relfrozenxid,
because you might restore your database from pg_dump or similar and
every table will have a very similar relfrozenxid and so then the
anti-wraparound logic fires for all of them at the same time. There
might be cases where MXIDs behave the same way, although I would think
it would be less common.
Anyway, solving that problem would be nice (particularly for xmin!),
but we shouldn't get into that with relation to this bug fix. It's a
problem, but one that will probably take a good deal of work to solve,
and certainly not something we would back-patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company