Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)

On Tue, Apr 21, 2015 at 12:34 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
>
> 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.
>

1. Do you think it makes sense to give warning in SetMultiXactIdLimit()
if we have already reached offsetWarnLimit as we give for multiWarnLimit?

2.
void
 MultiXactAdvanceOldest(MultiXactId oldestMulti, Oid oldestMultiDB)
 {
  if (MultiXactIdPrecedes(MultiXactState->oldestMultiXactId, oldestMulti))
  SetMultiXactIdLimit(oldestMulti, oldestMultiDB);
+ else
+ DetermineSafeOldestOffset(oldestMulti);
 }

Why we need to update offset stop/warn limits for the above case?
Won't it make the warning/error (pertaining to wrap around data loss)
to appear before it is required.

3.
@@ -1921,6 +1957,12 @@ StartupMultiXact(void)
  */
  pageno = MXOffsetToMemberPage(offset);
  MultiXactMemberCtl->shared->latest_page_number = pageno;
+
+ /*
+ * compute the oldest member we need to keep around to avoid old member
+ * data overrun.
+ */
+ DetermineSafeOldestOffset(MultiXactState->oldestMultiXactId);
 }

Do we need to try determining safeoldestoffset during startup considering
that we don't allow it in recovery (StartupMultiXact() seems to be called
only during recovery)

4.
AuxiliaryProcessMain()
{
..
/*
 * XLOG operations
 */
SetProcessingMode(NormalProcessing);

switch (MyAuxProcType)
{
case CheckerProcess:
/* don't set signals, they're useless here */
CheckerModeMain();
proc_exit(1); /* should never return */

case BootstrapProcess:
SetProcessingMode(BootstrapProcessing);
bootstrap_signals();
BootStrapXLOG();
BootstrapModeMain();
proc_exit(1); /* should never return */

..
}

Looking at above code, the new setting of processing mode for
BootstrapProcessing  looks slightly unlear, basically first we set
processing mode  as Normal and then set it to BootstrapProcessing,
may be we can add a comment there.

This solution seems like a good workaround for the problem reported,
however ideally there should be some way (via Vacuum/
Checkpoint) with which this increase of files can be prevented. I think
after your patch gets committed, we can try to devise a better design
to overcome this problem.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com