| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f |
| Date: | 2022-02-10 22:52:54 |
| Message-ID: | 20220210225254.pds2dowte5yophmr@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Hi,
On 2022-02-10 14:38:06 -0800, Andres Freund wrote:
> On 2022-02-10 14:58:57 -0500, Tom Lane wrote:
> > So it looks to me like the core problem is that pg_ctl's do_stop()
> > is too trusting: if it once sees the postmaster PID as alive, it
> > figures that's the end of the story.
>
> Agreed, that's a problem. Even if it wasn't the cause of slot tests on AIX.
Should we take the danger of postmaster dying without cleaning up the pid file
and then another process reusing that pid serious? That obviously could make
pg_ctl wait until timeout.
Postmaster always opening a named pipe or unix socket in the data directory
would allow to detect that, I guess. Or checking the shared memory segment for
attached processes, but that seems like a mess to do in pg_ctl.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-02-11 00:57:20 | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f |
| Previous Message | Andres Freund | 2022-02-10 22:38:06 | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f |