DBT creates multiple tmp tables when updating incremental tables causing serialization isolation violations on Redshift
See original GitHub issueDescribe the bug
We encounter serializable isolation violation
errors when updating incremental models. Upon debugging svl_statementtext
in Redshift we can see that two temporary tables are created almost in parallel (20 secs apart) reading from the same source table. (The source table is frequently updated via AWS DMS, synchronizing changes from a MySQL DB to our Redshift DWH.)
The creation of one of the temp tables is aborted due to concurrent access of the same source table (that has probably been changed in the meantime).
Steps To Reproduce
Model file in models/target_schema/test_table.sql
{{
config(
materialized='incremental'
)
}}
SELECT
*
FROM {{ source('source_schema',
'test_table')}}
{% if is_incremental() %}
where
updated > (select max(updated)
from {{ this }})
{% endif %}
Run script in bin/dbt_run_pipeline.sh
echo "Installing dbt dependencies"
dbt deps
echo "---Running tests---"
echo ""
dbt test --target prod --profiles-dir . --models target_schema --full-refresh
echo ""
echo "---Running transformations---"
dbt run --target prod --profiles-dir . --models target_schema --full-refresh
The source table should be changed frequently in Redshift, e.g. via AWS DMS replication task in CDC mode.
Expected behavior
Create only one temporary table that is then used to update the target table incrementally.
Screenshots and log output
Airflow logs (abbreviated)
[2020-12-17T16:07:41.613000] 16:07:41 | 2 of 86 START incremental model target_schema.test_table [RUN]
...
[2020-12-17T16:08:01.123000] 16:08:01 | 2 of 86 ERROR creating incremental model staging_process_engine.appointment_appointment [ [31mERROR [0m in 19.51s]
...
[2020-12-17T16:16:07.066000] 16:16:07 | Finished running 16 incremental models, 70 table models, 6 hooks in 514.47s.
[2020-12-17T16:16:08.197000] [ 31mCompleted with 14 errors and 0 warnings: [0m
...
[2020-12-17T16:16:08.198000] [33mDatabase Error in model test_table (models/target_schema/test_table.sql) [0m
[2020-12-17T16:16:08.198000] 1023
[2020-12-17T16:16:08.198000] DETAIL: Serializable isolation violation on table - 22123488, transactions forming the cycle are: 280864649, 280864380 (pid:2826)
[2020-12-17T16:16:08.198000] compiled SQL at target/run/dwh/models/target_schema/test_table.sql
Concurrent transaction logs in Redshift svl_statementtext:
"xid","pid","starttime","endtime","sequence","type","text","aborted"
280864380,2809,2020-12-17 16:07:31,2020-12-17 16:07:31,0,UTILITY,BEGIN,0
280864380,2809,2020-12-17 16:07:31,2020-12-17 16:07:33,0,QUERY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n \n\n create temporary table\n ""test_table",0
280864380,2809,2020-12-17 16:07:31,2020-12-17 16:07:33,1,QUERY,"__dbt_tmp20201217160730952436""\n \n \n as (\n \n\nSELECT \n *\nFROM ""dev"".""source_schema"".""test_table""\n\n\n where \n updated > (select max(updated)",0
280864380,2809,2020-12-17 16:07:31,2020-12-17 16:07:33,2,QUERY,"\n from ""dev"".""target_schema"".""test_table"")\n\n );\n",0
280864380,2809,2020-12-17 16:07:33,2020-12-17 16:07:34,0,UTILITY,Analyze test_table__dbt_tmp20201217160730952436,0
280864380,2809,2020-12-17 16:07:33,2020-12-17 16:07:33,0,QUERY,padb_fetch_sample: select * from test_table__dbt_tmp20201217160730952436,0
280864380,2809,2020-12-17 16:07:33,2020-12-17 16:07:34,0,QUERY,padb_fetch_sample: select * from test_table__dbt_tmp20201217160730952436,0
280864380,2809,2020-12-17 16:07:34,2020-12-17 16:07:34,0,UTILITY,BEGIN,0
280864380,2809,2020-12-17 16:07:36,2020-12-17 16:07:46,0,QUERY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n \n\n insert into ""dev"".""target_schema",0
280864380,2809,2020-12-17 16:07:36,2020-12-17 16:07:46,1,QUERY,".""test_table"" (""id"", ""firstname"", ""lastname"", ""status"", ""starttime"", ""endtime"", ""created"", ""updated""\n from ""test_table__dbt_tmp20201217160730952436""\n );\n",0
280864649,2826,2020-12-17 16:07:43,2020-12-17 16:07:43,0,UTILITY,BEGIN,1
280864649,2826,2020-12-17 16:07:44,2020-12-17 16:07:51,0,QUERY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n \n\n create temporary table\n ""test_table",1
280864649,2826,2020-12-17 16:07:44,2020-12-17 16:07:51,1,QUERY,"__dbt_tmp20201217160742605919""\n \n \n as (\n \n\nSELECT \n *\nFROM ""dev"".""source_schema"".""test_table""\n\n\n where \n updated > (select max(updated)",1
280864649,2826,2020-12-17 16:07:44,2020-12-17 16:07:51,2,QUERY,"\n from ""dev"".""target_schema"".""test_table"")\n\n );\n",1
280864380,2809,2020-12-17 16:07:46,2020-12-17 16:07:46,0,UTILITY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n GRANT SELECT ON ""dev"".""target_schema",0
280864380,2809,2020-12-17 16:07:46,2020-12-17 16:07:46,1,UTILITY,""".""test_table"" TO GROUP datamining\n",0
280864380,2809,2020-12-17 16:07:46,2020-12-17 16:07:48,0,UTILITY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n GRANT SELECT ON ""dev"".""target_schema",0
280864380,2809,2020-12-17 16:07:46,2020-12-17 16:07:48,1,UTILITY,""".""test_table"" TO etl\n",0
280864380,2809,2020-12-17 16:07:48,2020-12-17 16:07:48,0,UTILITY,"/* {""app"": ""dbt"", ""dbt_version"": ""0.18.1"", ""profile_name"": ""default"", ""target_name"": ""prod"", ""node_id"": ""model.dwh.test_table""} */\n\n GRANT ALL ON ""dev"".""target_schema"".""",0
280864380,2809,2020-12-17 16:07:48,2020-12-17 16:07:48,1,UTILITY,"test_table"" TO dbt\n",0
280864380,2809,2020-12-17 16:07:48,2020-12-17 16:07:48,0,UTILITY,COMMIT,0
280864649,2826,2020-12-17 16:07:51,2020-12-17 16:07:53,0,UTILITY,Analyze test_table__dbt_tmp20201217160742605919,1
280864649,2826,2020-12-17 16:07:51,2020-12-17 16:07:52,0,QUERY,padb_fetch_sample: select * from test_table__dbt_tmp20201217160742605919,1
280864649,2826,2020-12-17 16:07:52,2020-12-17 16:07:52,0,QUERY,padb_fetch_sample: select * from test_table__dbt_tmp20201217160742605919,1
280864649,2826,2020-12-17 16:07:53,2020-12-17 16:07:53,0,UTILITY,BEGIN,1
280864649,2826,2020-12-17 16:08:01,2020-12-17 16:08:01,0,UTILITY,ROLLBACK,1
System information
Which database are you using dbt with?
- postgres
- redshift
- bigquery
- snowflake
- other (specify: ____________)
The output of dbt --version
:
installed version: 0.18.1
latest version: 0.18.1
Up to date!
Plugins:
- snowflake: 0.18.1
- postgres: 0.18.1
- redshift: 0.18.1
- bigquery: 0.18.1
The operating system you’re using: Ubuntu 16.04
The output of python --version
:
3.7.8
Additional context
The issue has been noticed in our production environment where we are triggering DBT runs via an Airflow ECSOperator to launch the runs as AWS Fargate tasks.
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (4 by maintainers)
Top GitHub Comments
Ah, got it, @dankleiman. I was just too excited about solving the mystery 😃
@n0rritt Happy to re-open this one if you’ve been able to debug it further. As I posted in the related Slack thread, I think there has to be something else happening here to cause two simultaneous dbt runs.
@jtcohen6 I don’t want to go too off topic with this, but I’m tracking something similar and I think the output here is pointing to the model being executed twice.
The pattern I’m seeing involves two transactions that are colliding to produce the serializable isolation error.
From this query:
You can see:
Now, that looks to me like the model
model.flipside_dbt.terra_prices
is getting built twice?Transaction 239456987 makes it through the whole process:
We hit the conflict on transaction 239457044 before it can perform the merge operations.
~Interesting that the temp table is called
terra_prices__dbt_tmp20201223112640827311
in both cases?~ It’s not.EDIT: @jtcohen6 Apologies! This is a red-herring for being an issue with temp table creation in my case…I was able to use the dbt cloud api + debug logs to track down two different runs that were building overlapping models at the same time, causing the conflict above.