Graceful command exit using CTRL+C on MN #4958
Assignees
Labels
Comments
|
Also check that setting We basically need to convert all SYNC calls from ANs to DNs into async ones and check for interrupts in those. |
|
Might be related https://github.com/timescale/Support-Dev-Collab/issues/682 |
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 7, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 7, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 7, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 7, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 7, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
|
@erimatnor , @nikkhils do you think this will fix that test failure? |
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 8, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958, timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 12, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 13, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 13, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 14, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 14, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 14, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 15, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 15, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 16, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Dec 16, 2022
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 26, 2023
Refactor the use of libpq calls to data nodes so that they honor PostgreSQL interrupt handling (e.g., ctrl-c or `statement_timeout`) and don't block unnecessarily. To implement this behavior, data node connections are made non-blocking by default and all `libpq` functions are wrapped to integrate with PostgreSQL's signal handling (via `WaitEventSets`) when waiting for read or write readiness. A change is also made to the life-cycle management of `libpq` objects, including connections, and remote query results. Instead of tying these to transactions, they are now tied to the life-cycle of memory contexts using a callback. In most cases, the memory context a connection is allocated on has the same lifetime as transactions, but not always. For example, the connection cache lives across connections and is using a longer lived memory context. Previously that was handled as a special case where connections were marked to not auto close on transaction end. Closes timescale#4958 Closes timescale#2757
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 30, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 30, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 30, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Jan 31, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 1, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 1, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 2, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 2, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958.
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 3, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for timescale#4958. Refactor remote command execution function
erimatnor
added a commit
that referenced
this issue
Feb 3, 2023
The function to execute remote commands on data nodes used a blocking libpq API that doesn't integrate with PostgreSQL interrupt handling, making it impossible for a user or statement timeout to cancel a remote command. Refactor the remote command execution function to use a non-blocking API and integrate with PostgreSQL signal handling via WaitEventSets. Partial fix for #4958. Refactor remote command execution function
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 3, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Most of the COPY-related code (that calls libpq functions) has been moved to the remote connection module. Previously, similar code was duplicated across multiple locations. Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 3, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Most of the COPY-related code (that calls libpq functions) has been moved to the remote connection module. Previously, similar code was duplicated across multiple locations. Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 3, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Most of the COPY-related code (that calls libpq functions) has been moved to the remote connection module. Previously, similar code was duplicated across multiple locations. Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 13, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Most of the COPY-related code (that calls libpq functions) has been moved to the remote connection module. Previously, similar code was duplicated across multiple locations. Closes timescale#4958
erimatnor
added a commit
to erimatnor/timescaledb
that referenced
this issue
Feb 13, 2023
Refactor COPY code for both "in" and "out" mode so that it is non-blocking and interruptible. This will allow canceling queries and ingest paths that use COPY between the access node and data nodes. Canceling can be done using statement timeouts or user interrupts (ctrl-c). Most of the COPY-related code (that calls libpq functions) has been moved to the remote connection module. Previously, similar code was duplicated across multiple locations. Closes timescale#4958
|
multinode has been removed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: