| From: | Raúl Marín <admin(at)rmr(dot)ninja> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, git(at)rmr(dot)ninja |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16199: pg_restore stuck on interrupts |
| Date: | 2020-01-08 17:53:06 |
| Message-ID: | 1f13a999-6d9c-55ee-61fc-d5322be68fda@rmr.ninja |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 8/1/20 18:13, Tom Lane wrote:
> You didn't actually say, but you must be interrupting parallel restores
> with SIGINT or the like?
Yes, CI (Jenkins) is interrupted automatically with new pushes and
that's supposed to send a SIGTERM to the process group, which includes
the pg_restore process.
> 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?
Initially I didn't like this idea since that means not cleaning up
gnutls stuff, and modifying things related to crypto is always scary;
but following the same reasoning, I trust that any good cryto library
shouldn't leak anything important due to a fast exit.
I'll set up some of the servers to use _exit() for some days and see if
that fixes it.
Thanks!
Raúl Marín.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Prathmesh Agarwadekar | 2020-01-09 00:26:33 | Error while trying to open pgadmin |
| Previous Message | Tom Lane | 2020-01-08 17:13:35 | Re: BUG #16199: pg_restore stuck on interrupts |