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
