New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop distributed hypertable within procedure doesn't drop remote tables #3663
Comments
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Oct 9, 2021
When DROP being executed inside procedure ddl_command_start was not handled which lead to ignoring this operation on the data nodes. Fix timescale#3663
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Oct 9, 2021
When DROP being executed inside procedure ddl_command_start was not handled which lead to ignoring this operation on the data nodes. Fix timescale#3663
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Oct 12, 2021
When DROP being executed inside procedure ddl_command_start was not handled which lead to ignoring this operation on the data nodes. Fix timescale#3663
pmwkaa
added a commit
that referenced
this issue
Oct 12, 2021
When DROP being executed inside procedure ddl_command_start was not handled which lead to ignoring this operation on the data nodes. Fix #3663
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Oct 16, 2021
Make sure `ALTER TABLE SET (timescaledb.compress)` command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Oct 16, 2021
Make sure `ALTER TABLE SET (timescaledb.compress)` command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Nov 22, 2021
Make sure ALTER TABLE SET (timescaledb.compress) command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Nov 22, 2021
Make sure ALTER TABLE SET (timescaledb.compress) command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Nov 22, 2021
Make sure ALTER TABLE SET (timescaledb.compress) command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
pmwkaa
added a commit
to pmwkaa/timescaledb
that referenced
this issue
Nov 22, 2021
Make sure ALTER TABLE SET (timescaledb.compress) command properly propagated to the data nodes when executed within a procedure. This includes only test a case, actual fix was done in timescale#3663. Fix timescale#3705
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relevant system information:
postgres --version
): postgres (PostgreSQL) 13.4 (Debian 13.4-1.pgdg100+1)\dx
inpsql
): 2.4.1Describe the bug
When dropping a distributed hypertable within a procedure, only the table on the access node is dropped, while the table(s) on the data node(s) remain.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
success
Actual behavior
Additional context
I thought I saw another similar issue recently where someone reported problems running a DDL statement inside a procedure/function and it not distributing to data nodes properly. But now I can't find it :-/
The text was updated successfully, but these errors were encountered: