2019-12-02 03:18:56 +01:00
|
|
|
/*------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* Query cancellation support for frontend code
|
|
|
|
*
|
|
|
|
* Assorted utility functions to control query cancellation with signal
|
|
|
|
* handler for SIGINT.
|
|
|
|
*
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2019-12-02 03:18:56 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2022-08-09 04:21:37 +02:00
|
|
|
* src/fe_utils/cancel.c
|
2019-12-02 03:18:56 +01:00
|
|
|
*
|
|
|
|
*------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres_fe.h"
|
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2020-08-10 18:22:54 +02:00
|
|
|
#include "common/connect.h"
|
2019-12-02 03:18:56 +01:00
|
|
|
#include "fe_utils/cancel.h"
|
|
|
|
#include "fe_utils/string_utils.h"
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write a simple string to stderr --- must be safe in a signal handler.
|
|
|
|
* We ignore the write() result since there's not much we could do about it.
|
|
|
|
* Certain compilers make that harder than it ought to be.
|
|
|
|
*/
|
|
|
|
#define write_stderr(str) \
|
|
|
|
do { \
|
|
|
|
const char *str_ = (str); \
|
|
|
|
int rc_; \
|
|
|
|
rc_ = write(fileno(stderr), str_, strlen(str_)); \
|
|
|
|
(void) rc_; \
|
|
|
|
} while (0)
|
|
|
|
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
/*
|
|
|
|
* Contains all the information needed to cancel a query issued from
|
|
|
|
* a database connection to the backend.
|
|
|
|
*/
|
2019-12-02 03:18:56 +01:00
|
|
|
static PGcancel *volatile cancelConn = NULL;
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
|
2022-01-17 19:30:04 +01:00
|
|
|
/*
|
|
|
|
* Predetermined localized error strings --- needed to avoid trying
|
|
|
|
* to call gettext() from a signal handler.
|
|
|
|
*/
|
|
|
|
static const char *cancel_sent_msg = NULL;
|
|
|
|
static const char *cancel_not_sent_msg = NULL;
|
|
|
|
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
/*
|
Rethink definition of cancel.c's CancelRequested flag.
As it stands, this flag is only set when we've successfully sent a
cancel request, not if we get SIGINT and then fail to send a cancel.
However, for almost all callers, that's the Wrong Thing: we'd prefer
to abort processing after control-C even if no cancel could be sent.
As an example, since commit 1d468b9ad "pgbench -i" fails to give up
sending COPY data even after control-C, if the postmaster has been
stopped, which is clearly not what the code intends and not what anyone
would want. (The fact that it keeps going at all is the fault of a
separate bug in libpq, but not letting CancelRequested become set is
clearly not what we want here.)
The sole exception, as far as I can find, is that scripts_parallel.c's
ParallelSlotsGetIdle tries to consume a query result after issuing a
cancel, which of course might not terminate quickly if no cancel
happened. But that behavior was poorly thought out too. No user of
ParallelSlotsGetIdle tries to continue processing after a cancel,
so there is really no point in trying to clear the connection's state.
Moreover this has the same defect as for other users of cancel.c,
that if the cancel request fails for some reason then we end up with
control-C being completely ignored. (On top of that, select_loop failed
to distinguish clearly between SIGINT and other reasons for select(2)
failing, which means that it's possible that the existing code would
think that a cancel has been sent when it hasn't.)
Hence, redefine CancelRequested as simply meaning that SIGINT was
received. We could add a second flag with the other meaning, but
in the absence of any compelling argument why such a flag is needed,
I think it would just offer an opportunity for future callers to
get it wrong. Also remove the consumeQueryResult call in
ParallelSlotsGetIdle's failure exit. In passing, simplify the
API of select_loop.
It would now be possible to re-unify psql's cancel_pressed with
CancelRequested, partly undoing 5d43c3c54. But I'm not really
convinced that that's worth the trouble, so I left psql alone,
other than fixing a misleading comment.
This code is new in v13 (cf a4fd3aa71), so no need for back-patch.
Per investigation of a complaint from Andres Freund.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:07:31 +02:00
|
|
|
* CancelRequested is set when we receive SIGINT (or local equivalent).
|
|
|
|
* There is no provision in this module for resetting it; but applications
|
|
|
|
* might choose to clear it after successfully recovering from a cancel.
|
|
|
|
* Note that there is no guarantee that we successfully sent a Cancel request,
|
|
|
|
* or that the request will have any effect if we did send it.
|
Fix query cancellation handling in psql
The refactoring done in a4fd3aa for query cancellation has messed up
with the logic in psql by mixing CancelRequested and cancel_pressed,
breaking for example \watch. The former would be switched to true if a
cancellation request has been attempted and that it actually succeeded,
and the latter tracks if a cancellation attempt has been done.
This commit brings back the code of psql to a state consistent to what
it was before a4fd3aa, without giving up on the refactoring pieces
introduced. It should be actually possible to merge more both flags as
their concepts are close enough, however note that psql's --single-step
mode relies on cancel_pressed to be always set, so this requires more
careful analysis left for later.
While on it, fix the declarations of CancelRequested (in cancel.c) and
cancel_pressed (in psql) to be volatile sig_atomic_t. Previously,
both were declared as booleans, which should be fine on modern
platforms, but the C standard recommends the use of sig_atomic_t for
variables used in signal handlers. Note that since its introduction in
a1792320, CancelRequested declaration was not volatile.
Reported-by: Jeff Janes
Author: Michael Paquier
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com
2019-12-17 02:44:25 +01:00
|
|
|
*/
|
|
|
|
volatile sig_atomic_t CancelRequested = false;
|
2019-12-02 03:18:56 +01:00
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
static CRITICAL_SECTION cancelConnLock;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Additional callback for cancellations.
|
|
|
|
*/
|
|
|
|
static void (*cancel_callback) (void) = NULL;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SetCancelConn
|
|
|
|
*
|
|
|
|
* Set cancelConn to point to the current database connection.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SetCancelConn(PGconn *conn)
|
|
|
|
{
|
|
|
|
PGcancel *oldCancelConn;
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
EnterCriticalSection(&cancelConnLock);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Free the old one if we have one */
|
|
|
|
oldCancelConn = cancelConn;
|
|
|
|
|
|
|
|
/* be sure handle_sigint doesn't use pointer while freeing */
|
|
|
|
cancelConn = NULL;
|
|
|
|
|
|
|
|
if (oldCancelConn != NULL)
|
|
|
|
PQfreeCancel(oldCancelConn);
|
|
|
|
|
|
|
|
cancelConn = PQgetCancel(conn);
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
LeaveCriticalSection(&cancelConnLock);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ResetCancelConn
|
|
|
|
*
|
|
|
|
* Free the current cancel connection, if any, and set to NULL.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ResetCancelConn(void)
|
|
|
|
{
|
|
|
|
PGcancel *oldCancelConn;
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
EnterCriticalSection(&cancelConnLock);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
oldCancelConn = cancelConn;
|
|
|
|
|
|
|
|
/* be sure handle_sigint doesn't use pointer while freeing */
|
|
|
|
cancelConn = NULL;
|
|
|
|
|
|
|
|
if (oldCancelConn != NULL)
|
|
|
|
PQfreeCancel(oldCancelConn);
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
LeaveCriticalSection(&cancelConnLock);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Code to support query cancellation
|
|
|
|
*
|
|
|
|
* Note that sending the cancel directly from the signal handler is safe
|
|
|
|
* because PQcancel() is written to make it so. We use write() to report
|
|
|
|
* to stderr because it's better to use simple facilities in a signal
|
|
|
|
* handler.
|
|
|
|
*
|
|
|
|
* On Windows, the signal canceling happens on a separate thread, because
|
|
|
|
* that's how SetConsoleCtrlHandler works. The PQcancel function is safe
|
|
|
|
* for this (unlike PQrequestCancel). However, a CRITICAL_SECTION is required
|
|
|
|
* to protect the PGcancel structure against being changed while the signal
|
|
|
|
* thread is using it.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
|
|
|
|
/*
|
|
|
|
* handle_sigint
|
|
|
|
*
|
|
|
|
* Handle interrupt signals by canceling the current command, if cancelConn
|
|
|
|
* is set.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
handle_sigint(SIGNAL_ARGS)
|
|
|
|
{
|
|
|
|
char errbuf[256];
|
|
|
|
|
Rethink definition of cancel.c's CancelRequested flag.
As it stands, this flag is only set when we've successfully sent a
cancel request, not if we get SIGINT and then fail to send a cancel.
However, for almost all callers, that's the Wrong Thing: we'd prefer
to abort processing after control-C even if no cancel could be sent.
As an example, since commit 1d468b9ad "pgbench -i" fails to give up
sending COPY data even after control-C, if the postmaster has been
stopped, which is clearly not what the code intends and not what anyone
would want. (The fact that it keeps going at all is the fault of a
separate bug in libpq, but not letting CancelRequested become set is
clearly not what we want here.)
The sole exception, as far as I can find, is that scripts_parallel.c's
ParallelSlotsGetIdle tries to consume a query result after issuing a
cancel, which of course might not terminate quickly if no cancel
happened. But that behavior was poorly thought out too. No user of
ParallelSlotsGetIdle tries to continue processing after a cancel,
so there is really no point in trying to clear the connection's state.
Moreover this has the same defect as for other users of cancel.c,
that if the cancel request fails for some reason then we end up with
control-C being completely ignored. (On top of that, select_loop failed
to distinguish clearly between SIGINT and other reasons for select(2)
failing, which means that it's possible that the existing code would
think that a cancel has been sent when it hasn't.)
Hence, redefine CancelRequested as simply meaning that SIGINT was
received. We could add a second flag with the other meaning, but
in the absence of any compelling argument why such a flag is needed,
I think it would just offer an opportunity for future callers to
get it wrong. Also remove the consumeQueryResult call in
ParallelSlotsGetIdle's failure exit. In passing, simplify the
API of select_loop.
It would now be possible to re-unify psql's cancel_pressed with
CancelRequested, partly undoing 5d43c3c54. But I'm not really
convinced that that's worth the trouble, so I left psql alone,
other than fixing a misleading comment.
This code is new in v13 (cf a4fd3aa71), so no need for back-patch.
Per investigation of a complaint from Andres Freund.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:07:31 +02:00
|
|
|
CancelRequested = true;
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
if (cancel_callback != NULL)
|
|
|
|
cancel_callback();
|
|
|
|
|
|
|
|
/* Send QueryCancel if we are processing a database query */
|
|
|
|
if (cancelConn != NULL)
|
|
|
|
{
|
|
|
|
if (PQcancel(cancelConn, errbuf, sizeof(errbuf)))
|
|
|
|
{
|
2022-01-17 19:30:04 +01:00
|
|
|
write_stderr(cancel_sent_msg);
|
2019-12-02 03:18:56 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-01-17 19:30:04 +01:00
|
|
|
write_stderr(cancel_not_sent_msg);
|
2019-12-02 03:18:56 +01:00
|
|
|
write_stderr(errbuf);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* setup_cancel_handler
|
|
|
|
*
|
|
|
|
* Register query cancellation callback for SIGINT.
|
|
|
|
*/
|
|
|
|
void
|
2022-09-20 22:09:30 +02:00
|
|
|
setup_cancel_handler(void (*query_cancel_callback) (void))
|
2019-12-02 03:18:56 +01:00
|
|
|
{
|
2022-09-20 22:09:30 +02:00
|
|
|
cancel_callback = query_cancel_callback;
|
2022-01-17 19:30:04 +01:00
|
|
|
cancel_sent_msg = _("Cancel request sent\n");
|
|
|
|
cancel_not_sent_msg = _("Could not send cancel request: ");
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
pqsignal(SIGINT, handle_sigint);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* WIN32 */
|
|
|
|
|
|
|
|
static BOOL WINAPI
|
|
|
|
consoleHandler(DWORD dwCtrlType)
|
|
|
|
{
|
|
|
|
char errbuf[256];
|
|
|
|
|
|
|
|
if (dwCtrlType == CTRL_C_EVENT ||
|
|
|
|
dwCtrlType == CTRL_BREAK_EVENT)
|
|
|
|
{
|
Rethink definition of cancel.c's CancelRequested flag.
As it stands, this flag is only set when we've successfully sent a
cancel request, not if we get SIGINT and then fail to send a cancel.
However, for almost all callers, that's the Wrong Thing: we'd prefer
to abort processing after control-C even if no cancel could be sent.
As an example, since commit 1d468b9ad "pgbench -i" fails to give up
sending COPY data even after control-C, if the postmaster has been
stopped, which is clearly not what the code intends and not what anyone
would want. (The fact that it keeps going at all is the fault of a
separate bug in libpq, but not letting CancelRequested become set is
clearly not what we want here.)
The sole exception, as far as I can find, is that scripts_parallel.c's
ParallelSlotsGetIdle tries to consume a query result after issuing a
cancel, which of course might not terminate quickly if no cancel
happened. But that behavior was poorly thought out too. No user of
ParallelSlotsGetIdle tries to continue processing after a cancel,
so there is really no point in trying to clear the connection's state.
Moreover this has the same defect as for other users of cancel.c,
that if the cancel request fails for some reason then we end up with
control-C being completely ignored. (On top of that, select_loop failed
to distinguish clearly between SIGINT and other reasons for select(2)
failing, which means that it's possible that the existing code would
think that a cancel has been sent when it hasn't.)
Hence, redefine CancelRequested as simply meaning that SIGINT was
received. We could add a second flag with the other meaning, but
in the absence of any compelling argument why such a flag is needed,
I think it would just offer an opportunity for future callers to
get it wrong. Also remove the consumeQueryResult call in
ParallelSlotsGetIdle's failure exit. In passing, simplify the
API of select_loop.
It would now be possible to re-unify psql's cancel_pressed with
CancelRequested, partly undoing 5d43c3c54. But I'm not really
convinced that that's worth the trouble, so I left psql alone,
other than fixing a misleading comment.
This code is new in v13 (cf a4fd3aa71), so no need for back-patch.
Per investigation of a complaint from Andres Freund.
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-06-07 19:07:31 +02:00
|
|
|
CancelRequested = true;
|
|
|
|
|
2019-12-02 03:18:56 +01:00
|
|
|
if (cancel_callback != NULL)
|
|
|
|
cancel_callback();
|
|
|
|
|
|
|
|
/* Send QueryCancel if we are processing a database query */
|
|
|
|
EnterCriticalSection(&cancelConnLock);
|
|
|
|
if (cancelConn != NULL)
|
|
|
|
{
|
|
|
|
if (PQcancel(cancelConn, errbuf, sizeof(errbuf)))
|
|
|
|
{
|
2022-01-17 19:30:04 +01:00
|
|
|
write_stderr(cancel_sent_msg);
|
2019-12-02 03:18:56 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-01-17 19:30:04 +01:00
|
|
|
write_stderr(cancel_not_sent_msg);
|
2019-12-02 03:18:56 +01:00
|
|
|
write_stderr(errbuf);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
LeaveCriticalSection(&cancelConnLock);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
/* Return FALSE for any signals not being handled */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
setup_cancel_handler(void (*callback) (void))
|
|
|
|
{
|
|
|
|
cancel_callback = callback;
|
2022-01-17 19:30:04 +01:00
|
|
|
cancel_sent_msg = _("Cancel request sent\n");
|
|
|
|
cancel_not_sent_msg = _("Could not send cancel request: ");
|
2019-12-02 03:18:56 +01:00
|
|
|
|
|
|
|
InitializeCriticalSection(&cancelConnLock);
|
|
|
|
|
|
|
|
SetConsoleCtrlHandler(consoleHandler, TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* WIN32 */
|