-
Notifications
You must be signed in to change notification settings - Fork 670
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
Distribution key as varchar causing problems #6543
Comments
Dear Hackers, I have investigated this issue, and now I will tell you the results of my investigation for your reference:
|
I feel like there are 2 separate issues here:
|
I think the issue is specifically with the cast from varchar to text in the join clause.
|
Yes, if you still keep the varchar type, there is no problem. But this doesn't seem to be caused by citus, and maybe I haven't found it (if you know, you can tell me) |
@marcocitus My feeling is that the problem is not citus, but PostgreSQL's missing handling of varchar types |
The commit that introduced this regression is: eadc88a |
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
I have a fix ready in #6550 |
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The new way of skipping validation of foreign keys skipped the validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
DESCRIPTION: Fix regression in allowed foreign keys on distributed tables In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The way of skipping validation of foreign keys that was introduced in eadc88a was skipping validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
DESCRIPTION: Fix regression in allowed foreign keys on distributed tables In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The way of skipping validation of foreign keys that was introduced in eadc88a was skipping validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6543 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
DESCRIPTION: Fix foreign key validation skip at the end of shard move In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6550 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution.
DESCRIPTION: Fix regression in allowed foreign keys on distributed tables In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The way of skipping validation of foreign keys that was introduced in eadc88a was skipping validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543 (cherry picked from commit 7a7880a)
DESCRIPTION: Fix foreign key validation skip at the end of shard move In eadc88a we started completely skipping foreign key constraint validation at the end of a non blocking shard move, instead of only for foreign keys to reference tables. However, it turns out that this didn't work at all because of a hard to notice bug: By resetting the SkipConstraintValidation flag at the end of our utility hook, we actually make the SET command that sets it a no-op. This fixes that bug by removing the code that resets it. This is fine because #6543 removed the only place where we set the flag in C code. So the resetting of the flag has no purpose anymore. This PR also adds a regression test, because it turned out we didn't have any otherwise we would have caught that the feature was completely broken. It also moves the constraint validation skipping to the utility hook. The reason is that #6550 showed us that this is the better place to skip it, because it will also skip the planning phase and not just the execution. (cherry picked from commit 81dcddd)
DESCRIPTION: Fix regression in allowed foreign keys on distributed tables In commit eadc88a we changed how we skip foreign key validation. The goal was to skip it in more cases. However, one change had the unintended regression of introducing failures when trying to create certain foreign keys. This reverts that part of the change. The way of skipping validation of foreign keys that was introduced in eadc88a was skipping validation during execution. The reason that this caused this regression was because some foreign key validation queries already fail during planning. In those cases it never gets to the execution step where it would later be skipped. Fixes #6543
…6714) When auto_explain module is loaded and configured, EXPLAIN will be implicitly run for all the supported commands. Postgres does not support `EXPLAIN` for `ALTER` command. However, auto_explain will try to `EXPLAIN` other supported commands internally triggered by `ALTER`. For instance, `ALTER TABLE target_table ADD CONSTRAINT fkey_167 FOREIGN KEY (col_1) REFERENCES ref_table(key) ... ` command may trigger a SELECT command in the following form for foreign key validation purpose: `SELECT fk.col_1 FROM ONLY target_table fk LEFT OUTER JOIN ONLY ref_table pk ON ( pk.key OPERATOR(pg_catalog.=) fk.col_1) WHERE pk.key IS NULL AND (fk.col_1 IS NOT NULL) ` For Citus tables, the Citus utility hook should ensure that constraint validation is skipped for shell tables but they are done for shard tables. The reason behind this design choice can be summed up as: - An ALTER TABLE command via coordinator node is run in a distributed transaction. - Citus does not support nested distributed transactions. - A SELECT query on a distributed table (aka shell table) is also run in a distributed transaction. - Therefore, Citus does not support running a SELECT query on a shell table while an ALTER TABLE command is running. With eadc88a a bug is introduced breaking the skip constraint validation behaviour of Citus. With this change, we see that validation queries on distributed tables are triggered within `ALTER` command adding constraints with validation check. This regression did not cause an issue for regular use cases since the citus executor hook blocks those queries heuristically when there is an ALTER TABLE command in progress. The issue is surfaced as a crash (#6424 Workers, when configured to use auto_explain, crash during distributed transactions.) when auto_explain is enabled. This is due to auto_explain trying to execute the SELECT queries in a nested distributed transaction. Now since the regression with constraint validation is fixed in #6543, we should be able to remove the workaround.
…6714) When auto_explain module is loaded and configured, EXPLAIN will be implicitly run for all the supported commands. Postgres does not support `EXPLAIN` for `ALTER` command. However, auto_explain will try to `EXPLAIN` other supported commands internally triggered by `ALTER`. For instance, `ALTER TABLE target_table ADD CONSTRAINT fkey_167 FOREIGN KEY (col_1) REFERENCES ref_table(key) ... ` command may trigger a SELECT command in the following form for foreign key validation purpose: `SELECT fk.col_1 FROM ONLY target_table fk LEFT OUTER JOIN ONLY ref_table pk ON ( pk.key OPERATOR(pg_catalog.=) fk.col_1) WHERE pk.key IS NULL AND (fk.col_1 IS NOT NULL) ` For Citus tables, the Citus utility hook should ensure that constraint validation is skipped for shell tables but they are done for shard tables. The reason behind this design choice can be summed up as: - An ALTER TABLE command via coordinator node is run in a distributed transaction. - Citus does not support nested distributed transactions. - A SELECT query on a distributed table (aka shell table) is also run in a distributed transaction. - Therefore, Citus does not support running a SELECT query on a shell table while an ALTER TABLE command is running. With eadc88a a bug is introduced breaking the skip constraint validation behaviour of Citus. With this change, we see that validation queries on distributed tables are triggered within `ALTER` command adding constraints with validation check. This regression did not cause an issue for regular use cases since the citus executor hook blocks those queries heuristically when there is an ALTER TABLE command in progress. The issue is surfaced as a crash (#6424 Workers, when configured to use auto_explain, crash during distributed transactions.) when auto_explain is enabled. This is due to auto_explain trying to execute the SELECT queries in a nested distributed transaction. Now since the regression with constraint validation is fixed in #6543, we should be able to remove the workaround.
I am currently facing an issue with tenant_id being a varchar instead of integer. I simplified the example 👍
This works
this does NOT work
I am getting the following error
I am using the docker-compose found on the root of the github (citus 11.1)
What am I missing?
thank you.
The text was updated successfully, but these errors were encountered: