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: | Raw Message | Whole Thread | 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 |