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 <br...@momjian.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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
