Re: Redesigning postmaster death handling

On Thu, Aug 21, 2025 at 5:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.