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 */