-
Notifications
You must be signed in to change notification settings - Fork 17
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
Postgres __dbt_backup
model names may not be unique when multithreaded
#20
Comments
Thanks for raising this issue and doing that research @tweavers ! Does your example project consistently work if you add the following macro override to your project in order to set
{% macro postgres__make_backup_relation(base_relation, backup_relation_type, suffix) %}
{% set backup_relation = postgres__make_relation_with_suffix(base_relation, suffix, dstring=True) %}
{{ return(backup_relation.incorporate(type=backup_relation_type)) }}
{% endmacro %} |
The following setup was able to yield the same error you reported a majority of the time (but not every single time). But when I added
|
@dbeatty10 - appreciate the quick follow up. Confirming that the override macro is working - thank you!. We're seeing the backup tables now named like this:
Interestingly, the
|
Here's the only difference between 21c21
< alter table "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_reason_a" rename to "model_with_a_very_long_name_that_we_made_for_some_r__dbt_backup"
---
> alter table "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_reason_a" rename to "model_with_a_very_long_name_that_we_mad__dbt_backup135949342860"
26c26
< drop table if exists "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_r__dbt_backup" cascade
---
> drop table if exists "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_mad__dbt_backup135949342860" cascade When Here is a lightly formatted version of the queries for BEGIN
create table "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_reas__dbt_tmp" as (
-- depends on:
-- "postgres"."dbt_dbeatty"."empty_lookup_table"
select 'a' as id
);
alter table "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_reason_a" rename to "model_with_a_very_long_name_that_we_made_for_some_r__dbt_backup"
alter table "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_reas__dbt_tmp" rename to "model_with_a_very_long_name_that_we_made_for_some_reason_a"
COMMIT
drop table if exists "postgres"."dbt_dbeatty"."model_with_a_very_long_name_that_we_made_for_some_r__dbt_backup" cascade
|
This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days. |
Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers. |
Is this a new bug?
Current Behavior
dbt runs will occasionally fail due to
__dbt_backup
table names not being unique. This happens when we have very similarly named models (aka share the first 51+ characters) that are being updated at the same time in a multi-threaded run.These are shown by dbt as
database errors
Expected Behavior
__dbt_backup
table names should incorporate a unique identifier as part of the suffix to handle similarly named models. The adapter macro has a mechanism in place for this already with thedstring
parameter. This paramter is set to true for temporary tables but not backup tables.Relevant code block
Steps To Reproduce
dbt --log-level debug run --select <model_names> --threads 4
Relevant log output
Environment
Additional Context
No response
The text was updated successfully, but these errors were encountered: