1.1.0 has a breaking change in transaction semantics. Previous transaction semantics did not correctly emulate Postgres behavior.

• In 1.0.0 and earlier, multiple statements in a single Query message were each committed separately, as if they had arrived in individual Query messages. In 1.1.0, all statements in a single message are treated as an implicit transaction, with all statements being committed or rolled back atomically.
• In 1.0.0 and earlier, statements received via the extended query protocol (parse, bind, execute, etc.) used by many libraries were all committed independently unless wrapped in an explicit transaction with BEGIN. In 1.1.0, such statements are committed atomically when a Sync message is received.
• In 1.0.0 and earlier, statements that produced an error were treated as independent errors and additional statements in the same transaction could still succeed. In 1.1.0, any error in a transaction causes all subsequent statements to fail until a COMMIT or ROLLBACK is received.

This change is unlikely to break most customers, but in accordance with our release policy this change in behavior requires a minor version increment.

Merged PRs

doltgresql

• 3070: bug fix: implicit transactions Postgres's rules for handling implicit transactions are subtle and diverge dramatically from MySQL's. This PR implements the correct semantics for implicit transactions:
• Multiple statements in a single query message execute in an implicit transaction
• Queries using the extended query protocol all take place in an explicit transaction, with Sync triggering a commit There are lots of additional subtleties in this behavior, fully documented at https://www.postgresql.org/docs/current/protocol-flow.html
• 3069: Decorrelate EXISTS / NOT EXISTS queries Fix Doltgres's TypeSanitizer analyzer rule casting every *plan.ExistsSubquery node before GMS's unnestExistsSubqueries rule runs, which hid the node from that rule's pattern match and silently disabled EXISTS/NOT EXISTS decorrelation (semi/anti join rewrite) for every Doltgres query using them. Manually perf testing results (10k rows, indexed): a simple correlated EXISTS query dropped from ~18s to ~20ms, and a nested EXISTS/NOT EXISTS query that hadn't finished after 90s completed in ~2s, roughly three orders of magnitude on the query shapes this fixes.
• 3064: Fix goroutine deadlock from unlocked mutex during panic Fixes a deadlock in DoltgresType.IoOutput/ConvertToType where a panic while resolving a type's cast or output function (e.g. an index-out-of-range on an unexpected empty ResolvedTypes()) left the type's mutex locked forever, hanging every later query that touched the same type. Also adds a step in the CI workflow to check for signs of a timeout in the logs, and if so, errors with a message about a deadlock timeout.
• 3063: Accept transaction isolation levels, but always use REPEATABLE READ Follow Dolt's existing behavior to allow clients to specify a transaction isolation level, but still always use REPEATABLE READ. Also includes an update to the Doltgres SQL parser, to allow us to differentiate between specified isolation levels in the future.
• 3054: bug fix: SHOW support global settings A bug prevented SHOW from working with global settings.
• 3049: Fix panic in test query converter Fix a panic in the Doltgres' test query converter when processing DEFAULT values in ON DUPLICATE KEY UPDATE / UPDATE ... SET clauses. Fixes: https://github.com/dolthub/doltgresql/issues/3045
• 3041: bug fix for nonlocal tables to work in Doltgres Depends on: https://github.com/dolthub/dolt/pull/11406 Fixes: https://github.com/dolthub/doltgresql/issues/3035

Closed Issues

• 3036: Window functions returning the wrong results
• 3045: Doltgres panics on INSERT...ON DUPLICATE KEY UPDATE <col> = DEFAULT query
• 3035: non-local tables broken