Re: Redesigning postmaster death handling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Redesigning postmaster death handling
Date
Msg-id 1375963.1755754084@sss.pgh.pa.us
Whole thread Raw
In response to Redesigning postmaster death handling  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Redesigning postmaster death handling
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> Here's an experimental patch to fix our shutdown strategy on
> postmaster death, as discussed in a nearby report[1].

Thanks for tackling this topic.

> For systems lacking that facility, the idea I'm trying out here is
> that backends that detect the condition in WaitEventSetWait() should
> themselves blast all backends with SIGQUIT, in a sense taking over the
> role of the departed postmaster.

Hmm.  Up to now, we have not had an assumption that postmaster
children are aware of every other postmaster child.  In particular,
not all postmaster children have PGPROC entries.  How much does
this matter?  What happens if the shared PGPROC array is corrupt?

> I didn't really want any
> consensus/negotiation over who's going to do that, so... they all do.

Agreed on that point.

> Most of the patch is just removing hundreds of lines of errors and
> conditions and comments that were now unreachable.

The patch would likely be a lot more readable if you split out the
"delete unreachable code" part into a separate step.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: memory leak in logical WAL sender with pgoutput's cachectx
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: memory leak in logical WAL sender with pgoutput's cachectx