{"push_id":646950444,"size":1,"distinct_size":1,"ref":"refs/heads/REL9_3_STABLE","head":"e2eda4b1159aecd222357db9310aab6d66067d50","before":"723613edf195ffd8decdd4971a2d6b21d75b6d81","commits":[{"sha":"e2eda4b1159aecd222357db9310aab6d66067d50","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Protect against multixact members wraparound\n\nMultixact member files are subject to early wraparound overflow and\nremoval: if the average multixact size is above a certain threshold (see\nnote below) the protections against offset overflow are not enough:\nduring multixact truncation at checkpoint time, some\npg_multixact/members files would be removed because the server considers\nthem to be old and not needed anymore.  This leads to loss of files that\nare critical to interpret existing tuples's Xmax values.\n\nTo protect against this, since we don't have enough info in pg_control\nand we can't modify it in old branches, we maintain shared memory state\nabout the oldest value that we need to keep; we use this during new\nmultixact creation to abort if an old still-needed file would get\noverwritten.  This value is kept up to date by checkpoints, which makes\nit not completely accurate but should be good enough.  We start emitting\nwarnings sometime earlier, so that the eventual multixact-shutdown\ndoesn't take DBAs completely by surprise (more precisely: once 20\nmembers SLRU segments are remaining before shutdown.)\n\nOn troublesome average multixact size: The threshold size depends on the\nmultixact freeze parameters. The oldest age is related to the greater of\nmultixact_freeze_table_age and multixact_freeze_min_age: anything\nolder than that should be removed promptly by autovacuum.  If autovacuum\nis keeping up with multixact freezing, the troublesome multixact average\nsize is\n\t(2^32-1) / Max(freeze table age, freeze min age)\nor around 28 members per multixact.  Having an average multixact size\nlarger than that will eventually cause new multixact data to overwrite\nthe data area for older multixacts.  (If autovacuum is not able to keep\nup, or there are errors in vacuuming, the actual maximum is\nmultixact_freeeze_max_age instead, at which point multixact generation\nis stopped completely.  The default value for this limit is 400 million,\nwhich means that the multixact size that would cause trouble is about 10\nmembers).\n\nInitial bug report by Timothy Garnett, bug #12990\nBackpatch to 9.3, where the problem was introduced.\n\nAuthors: Álvaro Herrera, Thomas Munro\nReviews: Thomas Munro, Amit Kapila, Robert Haas, Kevin Grittner","distinct":true,"url":"https://api.github.com/repos/postgres/postgres/commits/e2eda4b1159aecd222357db9310aab6d66067d50"}]}