fix: concurrent-incremental catalog deadlock, and (nolock) on the remaining catalog lookups

[axellpadilla]

Two independent catalog-locking fixes, plus the changelog bookkeeping that follows from #791.

1. Concurrent incremental models deadlock at threads > 1 (7fe0f06)

Two incremental models running concurrently with dbt_sqlserver_use_dbt_transactions: True deadlock with error 1205. The victim graph is an X/S inversion over sys.sysschobjs index nc1 — system catalog rows, not user data.

The temp-relation build (CREATE OR ALTER VIEW …__dbt_tmp_vw → SELECT * INTO …__dbt_tmp → DROP VIEW) is all catalog DDL, and it was running inside the materialization's ambient transaction, so its exclusive key locks were held until commit while a second worker's name resolution asked for shared locks on the same rows.

Nothing in that build needs a transaction — the relation is throwaway. The transaction was being opened accidentally, by a read-only catalog lookup (find_references in sqlserver__get_drop_sql) that used statement()'s default auto_begin=True. dbt-adapters' own relations/drop.sql already wraps the surrounding drop in auto_begin=False; this override just missed it.

• relation.sql — find_references runs with auto_begin=false, so the temp build autocommits statement by statement and releases catalog locks as it goes.
• incremental.sql — the fresh-create / full-refresh statement('main') batch is also create_table_as DDL, so it runs with auto_begin=False; commit_if_open / begin_if_closed after it reopen the ambient transaction for the swap and the tail. The incremental branch keeps the default auto_begin, so its strategy DML stays atomic through adapter.commit().
• create.sql — because the temp build now commits standalone, a crashed run can leave a throwaway table behind. SELECT * INTO drops adapter-generated throwaways first instead of failing the next run with Msg 2714. A fresh create of a real target still surfaces 2714 rather than silently destroying an object dbt does not know about.
• hooks.sql — the COMMIT before the first transaction: false hook is now guarded with @@TRANCOUNT > 0. It was only ever safe because something had accidentally auto-begun a transaction; with that removed it raised Msg 3902.

Pre-hook rollback semantics are unchanged: nothing is committed early, dbt only declines to open a transaction for a read. A transaction: true pre-hook still opens one, and the temp build correctly joins it.

2. Un-hinted catalog lookups block on unrelated writers (1596c98, d0e76c5)

SQL Server holds transaction-scoped exclusive locks on the system catalog for the duration of any CREATE/ALTER/DROP. A catalog read from another session under READ COMMITTED waits for those, and the default LOCK_TIMEOUT is -1 — so it waits forever. dbt appears to hang, with no error and no visible failure.

information_schema_hints() (with (nolock)) is the existing answer and is already applied at ~60 sites. These were missed:

macro	file
get_relation_last_modified	metadata.sql
drop_fk_constraints, drop_pk_constraints, drop_fk_references	indexes.sql
list_nonclustered_rowstore_indexes	indexes.sql
find_references	relation.sql

Measured against a second session holding 40 uncommitted CREATE statements in the same schema, reader at LOCK_TIMEOUT 5000 so blocking is observable rather than indefinite:

query	no hint	with (nolock)
get_relation_last_modified	blocked 5.00s	0.00s
drop_fk_references	blocked 5.02s	0.01s
drop_pk_constraints	blocked 5.01s	0.01s
list_relations — already hinted, run un-hinted as a control	blocked 5.00s	0.00s

The control row confirms the existing hints are load-bearing rather than decorative. find_references did not block in measurement — its plan seeks sys.sql_expression_dependencies first and reaches sys.objects by object_id on the clustered index — but it is the same class of read-only discovery query, so it is hinted for consistency rather than left as the odd one out.

with (nolock) is preferred over SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED because it is scoped per table reference: it cannot leak a dirty read onto user data the way a session-level isolation change would.

Deliberately left un-hinted

Catalog reads that act as correctness guards rather than discovery: the schema-exists check before CREATE SCHEMA, the principal-exists check in apply_grants, and the dbt_full_refresh_incomplete extended-property marker.

The first two provably cannot block — they are literal-name seeks, and stay at 0.00s even under 20 uncommitted CREATE SCHEMA / CREATE USER statements. The marker read does block, and that is correct behaviour: the marker is dropped inside an explicit transaction that wraps the whole bulk load, so a dirty read there would see it already gone while the rebuild is still in flight and could still roll back — letting a second invocation append onto a half-rebuilt table, which is exactly what the marker exists to prevent. Blocking is the interlock working; the reader waits for the rebuild to commit or roll back and then gets the true answer.

3. Changelog (29b1ab5)

Both fixes are filed under ### v1.11.0, not ### v1.12.0, because they ship in v1.11.0 via #791 — v1.11.0 final has not been released yet, only v1.11.0rc1. dbt_sqlserver_use_dbt_transactions is described as "(opt-in in 1.11, the default from 1.12)", which is what the flag actually does on that release. v1.12.0's Bugfixes section is empty as a result and is dropped.

Backport

1596c98 is deliberately free of any CHANGELOG change so it cherry-picks clean. Verified against release/v1.11 (#791) as well as the v1.10.1 and v1.9.2 tags; on 1.10 and 1.9 the indexes.sql hunks conflict on adjacent QUOTENAME hardening that landed later on master, and the resolution is noted in the commit message.

Companion PR: #791