Thomas Munro wrote: > I have finally reproduced that error! See attached repro shell script. > > The conditions are: > > 1. next multixact == oldest multixact (no active multixacts, pointing > past the end) > 2. next multixact would be the first item on a new page (multixact % 2048 == 0) > 3. the page must not be the first in a segment (or we'd get the > read-zeroes case) > > That gives you odds of 1/2048 * 31/32 * (probability of a wraparound > vacuum followed by no multixact creations right before your backup > checkpoint). That seems like reasonably low odds... if it happened > twice in a row, maybe I'm missing something here and there is some > other way to get this... Thanks, this is pretty cool (as far as these things go), but it's not the scenario I see, in which the complained-about segment is very old by the time it's truncated away by a checkpoint after freeze. Segment requested by checkpoint.oldestMulti is 0046 (offset 140k something -- just to clarify it's not at segment boundary), and the base backup contains segments from 004B to 00D5. My problem scenario has oldestMulti close to 5 million and nextMulti close to 14 million. -- Á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
