Alvaro Herrera wrote:
> The fix is to raise an ERROR when generating a new multixact, if we
> detect that doing so would get close to the oldest multixact that the
> system knows about. If that happens, the solution is to vacuum so that
> the "oldest" point is advanced a bit more and you have room to generate
> more multixacts. In production, you would typically adjust the
> multixact freeze parameters so that "oldest multixact" is advanced more
> aggressively and you don't hit the ERROR.
Here's a patch. I have tested locally and it closes the issue for me.
If those affected can confirm that it stops the file removal from
happening, I'd appreciate it.
It would be much better to avoid that additional file reading, but it
seems difficult (read: I don't see how) without changing pg_control.
Note: in bootstrap.c, I had to move setting the bootstrap a bit earlier.
Otherwise, the is-in-bootstrap mode test returned false while
bootstrapping multixact, so initdb would fail on the initial phase
because of trying to read pg_multixact/offset/0000 which hasn't been
created at that point. The amount of code that runs in the bootstrap
mode after this change that wasn't running in bootstrap mode previously
is pretty tiny and shouldn't cause any problem -- it's essentially
the whole of BootStrapXLOG().
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
