| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Race conditions with checkpointer and shutdown |
| Date: | 2019-04-18 21:58:40 |
| Message-ID: | CA+hUKGJE-VNHzkFp7MnvX_wXoVVxkHLfG19qFUzx80+vxYRqdg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 19, 2019 at 2:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Question is, what other theory has anybody got?
I wondered if there might be a way for PostmasterStateMachine() to be
reached with without signals blocked, in the case where we fork a
fresh checkpointers, and then it misses the SIGUSR2 that we
immediately send because it hasn't installed its handler yet. But I
can't see it.
This is a curious thing from dragonet's log:
2019-04-16 08:23:24.178 CEST [8335] LOG: received fast shutdown request
2019-04-16 08:23:24.178 CEST [8335] LOG: aborting any active transactions
2019-04-16 08:23:24.178 CEST [8393] FATAL: terminating walreceiver
process due to administrator command
2019-04-16 08:28:23.166 CEST [8337] LOG: restartpoint starting: time
LogCheckpointStart() is the thing that writes "starting: ...", and it
prefers to report "shutdown" over "time", but it didn't.
--
Thomas Munro
https://enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-04-18 22:22:41 | Re: Race conditions with checkpointer and shutdown |
| Previous Message | Tom Lane | 2019-04-18 21:57:39 | Re: Race conditions with checkpointer and shutdown |