Thread: pg_restore cancel TODO
I've added the TODO item:
The context where this arises is that I want to populate data into a new installation compiled with a patch under review, but immediately get error messages indicating I forgot to install a required extension. I hit ctrl-C so I can fix the problem, but it keeps running anyway.
Cheers,
Jeff
On Wed, Oct 14, 2015 at 09:34:04AM -0700, Jeff Janes wrote: > I've added the TODO item: > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the keyboard) > make it cancel the children processes. > > The context where this arises is that I want to populate data into a new > installation compiled with a patch under review, but immediately get error > messages indicating I forgot to install a required extension. I hit ctrl-C so > I can fix the problem, but it keeps running anyway. OK, we will need to look at that at some point. I am not sure we have any mechanism now to close those parallel processes. -- Bruce Momjian <bruce@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 +
Jeff Janes wrote: > I've added the TODO item: > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > keyboard) make it cancel the children processes. > > The context where this arises is that I want to populate data into a new > installation compiled with a patch under review, but immediately get error > messages indicating I forgot to install a required extension. I hit ctrl-C > so I can fix the problem, but it keeps running anyway. This looks more like a bug to me than a To-do item. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Oct 19, 2015 at 11:51:00AM -0300, Alvaro Herrera wrote: > Jeff Janes wrote: > > I've added the TODO item: > > > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > > keyboard) make it cancel the children processes. > > > > The context where this arises is that I want to populate data into a new > > installation compiled with a patch under review, but immediately get error > > messages indicating I forgot to install a required extension. I hit ctrl-C > > so I can fix the problem, but it keeps running anyway. > > This looks more like a bug to me than a To-do item. Uh, many TODO items are bugs. -- Bruce Momjian <bruce@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 +
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Jeff Janes wrote:
>> I've added the TODO item:
>>
>> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the
>> keyboard) make it cancel the children processes.
>>
>> The context where this arises is that I want to populate data into a new
>> installation compiled with a patch under review, but immediately get error
>> messages indicating I forgot to install a required extension. I hit ctrl-C
>> so I can fix the problem, but it keeps running anyway.
> This looks more like a bug to me than a To-do item.
Why doesn't the control-C kill all the child processes automatically?
I'd have expected it to ...
regards, tom lane
On Mon, Oct 19, 2015 at 08:28:34AM -0700, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Jeff Janes wrote: > >> I've added the TODO item: > >> > >> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > >> keyboard) make it cancel the children processes. > >> > >> The context where this arises is that I want to populate data into a new > >> installation compiled with a patch under review, but immediately get error > >> messages indicating I forgot to install a required extension. I hit ctrl-C > >> so I can fix the problem, but it keeps running anyway. > > > This looks more like a bug to me than a To-do item. > > Why doesn't the control-C kill all the child processes automatically? > I'd have expected it to ... I don't know. On Unix we use fork() and on Windows we use thread. It is not clear in the TODO list which platform this is for. I don't see any signal control in the pg_upgrade source code. -- Bruce Momjian <bruce@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 +
On Mon, Oct 19, 2015 at 8:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Jeff Janes wrote:
>> I've added the TODO item:
>>
>> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the
>> keyboard) make it cancel the children processes.
>>
>> The context where this arises is that I want to populate data into a new
>> installation compiled with a patch under review, but immediately get error
>> messages indicating I forgot to install a required extension. I hit ctrl-C
>> so I can fix the problem, but it keeps running anyway.
> This looks more like a bug to me than a To-do item.
Why doesn't the control-C kill all the child processes automatically?
I'd have expected it to ...
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)
Cheers,
Jeff
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@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 +
On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian <bruce@momjian.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.
On 10/19/2015 09:47 AM, Jeff Janes wrote: > On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian <bruce@momjian.us > <mailto:bruce@momjian.us>> wrote: > > 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) Yes it does. jD > > Jeff. -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. New rule for social situations: "If you think to yourself not even JD would say this..." Stop and shut your mouth. It's going to be bad.