Re: Redesigning postmaster death handling

On Thu, Aug 21, 2025 at 5:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?

It's also how we set latches, but yeah it's certainly an issue.

Other ideas:

1.  My other patch that used O_ASYNC (= ask the kernel to send SIGIO
when the pipe becomes readable) worked, but required a pipe or socket
pair per backend and is not actually in any standard.  I think it is
available almost everywhere anyway.  I could rejuvenate that just to
try out again.

2.  I wonder if we could make better use of session IDs.  I understand
that we use them to signal eg archiver + its children, but I wonder if
we could use a different granularity.  postmaster's sid for most
stuff, and per-backend sids when really needed, and then you just have
to signal a small number of sessions, perhaps more than one but not
much more.  We pretend that setsid is optional but it's old POSIX and
everywhere.  I also know that Windows has a similar thing, I just
haven't looked into it.

> > 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.

Will do.