The motivation for a crash and restart cycle when a backend dies is
that it might have corrupted shared memory on the way down; and we
can't recover reliably except by reinitializing everything. But that
doesn't apply to processes that don't touch shared memory. Currently,
there's nothing to prevent a background worker that doesn't request
shared memory access from touching shared memory anyway, but that's a
separate bug.
Previous to this commit, the coding in postmaster.c was inconsistent:
an exit status other than 0 or 1 didn't provoke a crash-and-restart,
but failure to release the postmaster child slot did. This change
makes those cases consistent.
HandleChildCrash(pid, exitstatus, namebuf);
return true;
}
- }
- if (!ReleasePostmasterChildSlot(rw->rw_child_slot))
- {
- /*
- * Uh-oh, the child failed to clean itself up. Treat as a crash
- * after all.
- */
- rw->rw_crashed_at = GetCurrentTimestamp();
- HandleChildCrash(pid, exitstatus, namebuf);
- return true;
+ if (!ReleasePostmasterChildSlot(rw->rw_child_slot))
+ {
+ /*
+ * Uh-oh, the child failed to clean itself up. Treat as a
+ * crash after all.
+ */
+ rw->rw_crashed_at = GetCurrentTimestamp();
+ HandleChildCrash(pid, exitstatus, namebuf);
+ return true;
+ }
}
/* Get it out of the BackendList and clear out remaining data */