From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_restore cancel TODO |
Date: | 2015-10-19 16:37:41 |
Message-ID: | 20151019163741.GG24392@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 19, 2015 at 09:26:21AM -0700, Jeff Janes wrote:
> It seems like gdb eats signals that you send a process while it is being
> debugged, so it is hard to figure out what is going on. From strace, it looks
> like the children do receive a signal but either ignore it, or set a flag and
> then ignore that.
>
> It doesn't continue to load the entire dump file, it exits once they complete
> the current assignment and ask the parent for more work.
>
> Could just be a matter of adding the local equivalent of CHECK_FOR_INTERRUPTS
> in the part of the code that spools COPY data to the backends? I'm not sure
> what would happen if it were in the index/constraint building phase, I've never
> let it get that far when it reported errors early on.
>
> (This is linux, sorry for not making that clear)
Well, we are not running COPY in pg_upgrade, just the DDL commands.
Index creation is on empty tables, so it should be very quick. What
should basically happen is that the pg_restore child processes should
exit as forked children, and then the backends for these pg_restore
proceses should then exit. My guess is that this problem is not
pg_upgrade-specific as there is no signal control in pg_upgrade --- you
are just getting the defaults.
(Updated TODO to mention Linux.)
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-10-19 16:47:04 | Re: pg_restore cancel TODO |
Previous Message | Jeff Janes | 2015-10-19 16:26:21 | Re: pg_restore cancel TODO |