Re: pg_restore cancel TODO

On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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.)
>

Sorry, I don't know how I managed to screw this up so much. pg_restore,
not pg_upgrade. I've never looked into pg_restore much until recently, so
my fingers just autocomplete to the one I'm more used to. Let me go fix
the TODO page. (I'm pretty sure pg_upgrade terminates itself very early
on upon missing extensions)

Jeff.