Keegan Carruthers-Smith e93b69bef2 migrations: use COMMIT AND CHAIN for tenant_id (#64431) ... We dived into our go postgres driver and when executing a migration it is executed as a "simple query". Postgres in this case automatically wraps the collection of statements in a transaction, unless it contains transaction statements. So our last attempt at removing the transaction failed. In this attempt we use COMMIT AND CHAIN after each table alter. What this does is commit the current transaction and then starts it up again. From the perspective of the go driver, it is as if there was only one transaction. We then switch the migration to using a transaction to ensure the go drivers clean up the postgres connection in case of failure. IE if a query manually starts a transaction and does not clean up, the connection will be marked as broken for the next person who gets the connection from the pool. By wrapping in go's transaction code the connection will be properly cleaned up. Test Plan: All continuous environments have already succeeded or failed on this migration number. So we will manually run this again against them with the migrator code to ensure the same code paths. If they succeed we will keep code as is, otherwise we will rollback. Additionally we did lots of adhoc testing to understand the characteristics of go and transaction handling. Co-authored-by: Erik Seliger <erikseliger@me.com>		2024-08-13 11:59:59 +00:00
..
5.1.0	bzl: rework migration schemas generation (#57511)	2023-10-10 17:19:47 +02:00
5.6.0	migrations: use COMMIT AND CHAIN for tenant_id (#64431)	2024-08-13 11:59:59 +00:00