Joshua D. Drake wrote:
> I believe there are likely quite a few parties willing to help test, if we
> knew how?
The code involved is related to checkpoints, pg_basebackups that take a
long time to run, and multixact freezing and truncation. If you can set
up test servers that eat lots of multixacts(*), then have many multixact
freezes and truncations occur, that would probably hit the right spots.
(You can set very frequent freezing by lowering
vacuum_multixact_freeze_min_age and vacuum_multixact_freeze_table_age
settings. Perhaps changing multixact_freeze_max_age would lead to other
interesting results too. Truncation occurs during checkpoint, some time
after freezing, so it's probably good that those are frequent too.)
Also, pg_upgrade prior to 9.3.4 is able to produce database with
invalid oldestMulti=1, if you start from a 9.2-or-earlier database that
has already consumed some number of multis. It would be good to test
starting from those, too, just to make sure the mechanism that deals
with that is good. There are at least two variations: those that have
nextMulti larger than 65k but less than 2 billion, and those that have
nextMulti closer to 4 billion. (I think a 9.2 database with nextMulti
less than 65k is uninteresting, because the resulting oldestMulti=1 is
the correct value there.)
(*) Thomas Munro posted a sample program that does that; I believe with
minimal changes you could turn it into infinite looping instead of a
pre-set number of iteration. Also, perhaps it's possible to come up
with programs that consume multixacts even faster than that, and that
create larger multixacts too. All variations are useful.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services