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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
