Re: canceling query

> > The backend should exit automatically when the user exits psql. How
> did
> > you exit psql? If you just closed the window, I think the
> query will
> > keep going even on Unix.
>
> I pressed ctrl-c from psql. The reason I am posting this on
> this list is because I am pretty sure this involves signal handling.

This is because there is no Ctrl-C handler in psql on win32. There was a
patch for this which was "almost complete", but it was not fully
thread-safe. The window of error is very small, but it's there. Perhaps
we can live with that since it's a client (if you hit the very small
window, you'll get a segfault or similar). If so, that patch acn
probably still be applied.

> To be specific: is the query cancel routine checking pending
> signals (using the win32 signal polling routine) and if so,
> is it properly catching the signal? (If not, I'll just
> properly wait until it is :) ). I suppose it is also possible
> my query is not checking to see if it cancelled.

There is no query cancel sent, thus the signal is not sent :-)

It should die once it tries to send data down the TCP connection,
though. Since the other end of the socket is gone. Do you know if your
query gets that for, or is it still executing?

> Following exiting psql, pg_stat_activity reports query still
> running...since I used big tables, it basically runes forever
> until I bring down the postmaster.

Yes. Or you can use my pg_kill_backend() function *cough*. Ok, yeah, I
remember the discussion. I'm working on fixing it up per the result of
that discussino, but I'm not done yet.
Either that, or you can use a small commandline tool to send the "new
style kill signal" o the backend. I'll see if we can get these files up
on the pg win32 status page for now, so you have some kind of tool for
now.

There really should be no need to bring down the entire postmaster.

> Also interesting is that when I kill the running backend it
> kills the postmaster (I know you are not supposed to do
> this). Here is the log:
>
> LOG: database system was shut down at 2004-04-19 08:14:01
> Eastern Daylight Time
> LOG: checkpoint record is at 0/2D715018
> LOG: redo record is at 0/2D715018; undo record is at 0/0;
> shutdown TRUE
> LOG: next transaction ID: 664978; next OID: 27086
> LOG: database system is ready
> ERROR: relation "order_file" does not exist
> LOG: could not send data to client: Unknown error
> LOG: server process (PID 3104) was terminated by signal 1
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another
> server process
> DETAIL: The postmaster has commanded this server process to
> roll back the current transaction and e xit, because another
> server process exited abnormally and possibly corrupted shared memory.
> HINT: In a moment you should be able to reconnect to the
> database and repeat your command.
> LOG: all server processes terminated; reinitializing
> FATAL: could not attach to proper memory at fixed address:
> shmget(key=5432001, addr=00F60000) faile
> d: No such file or directory

Now, that looks like a bug :-) If you kill just the backend, the
postmaster should still survive. I think it used to do this, must've
been one of the recent changes that broke it. Needs further digging in.

/Magnus