Re: BUG #16199: pg_restore stuck on interrupts
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: git@rmr.ninja
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-01-08T17:13:35Z
Lists: pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes: > We are seeing stuck pg_restore processes in several of our CI servers, both > with PG10 (10.2) and PG11 (11.5). You didn't actually say, but you must be interrupting parallel restores with SIGINT or the like? > I have a some extra processes with the same issue (7 full stacks out of 20, > the others are garbage) and, from what I see, they all have in common that > the process has received a signal while it was doing a memory operation, > either a malloc or a free: Yeah. Ugh :-( > I think if would be safer to use a similar approach to other processes, that > is use the handler to only enable a global flag and check that in the main > loop, but I'm having a hard time locating what the proper place to check the > flag would be. I think the odds of that being an improvement are minimal --- you'd be trading a risk of failure during exit for a risk of not exiting (in any timely fashion) in the first place. sigTermHandler tries to be safe to run in a signal context, but I'm afraid we didn't think hard about what exit() might call. The way I'd be inclined to fix this is to call _exit() instead of exit(), and the heck with what any atexit handlers think. Can you try that and see if it improves matters for you? regards, tom lane
Commits
-
Fix pg_dump's sigTermHandler() to use _exit() not exit().
- 42e538fe673b 9.4.26 landed
- cd23a2019c4b 13.0 landed
- b1392a950201 9.5.21 landed
- 71b121f42548 12.2 landed
- 6f6daa1be785 10.12 landed
- 4ea5cf403824 11.7 landed
- 208e262f9246 9.6.17 landed