| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Kuzmenkov <akuzmenkov(at)tigerdata(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: "pg_ctl stop" stops working after a backend crash |
| Date: | 2026-03-06 20:06:43 |
| Message-ID: | 526445.1772827603@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Kuzmenkov <akuzmenkov(at)tigerdata(dot)com> writes:
> I noticed that sometimes, when I'm running the regression tests and a
> backend crashes, the postmaster can get stuck in some weird state
> where it doesn't terminate and doesn't respond to `pg_ctl stop`
> anymore. I can semi-reliably reproduce this on 18.3 using a simple
> script below.
I experimented with this a bit. I failed to reproduce it with
your example, but it did happen once I reduced the "sleep 0.01"
to "sleep 0.001". So apparently, the postmaster misbehaves if
the stop signal arrives soon enough after a child crash (and
the window is tight enough that it's not too surprising we
hadn't noticed). Didn't look at the logic.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-06 20:50:56 | Re: Bypassing cursors in postgres_fdw to enable parallel plans |
| Previous Message | Nathan Bossart | 2026-03-06 20:03:04 | Re: pg_dumpall --roles-only interact with other options |