> ## Documentation Index > Fetch the complete documentation index at: https://planetscale.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Long-running transactions export const PlatformAvailability = ({current, vitess, postgres}) => { const docsHref = path => { if (!path) return path; const normalized = path.startsWith('/') ? path : `/${path}`; return normalized; }; const labels = { vitess: 'Vitess', postgres: 'Postgres' }; if (current === 'both') { return

Vitess and Postgres

; } const hasVitess = current === 'vitess' || Boolean(vitess); const hasPostgres = current === 'postgres' || Boolean(postgres); const only = !(hasVitess && hasPostgres); const engines = []; if (current === 'vitess' || current === 'postgres') engines.push(current); if (hasVitess && current !== 'vitess') engines.push('vitess'); if (hasPostgres && current !== 'postgres') engines.push('postgres'); return

{engines.map(engine => { const isCurrent = current === engine; const href = docsHref(engine === 'vitess' ? vitess : postgres); const label = only ? `${labels[engine]} only` : labels[engine]; const state = isCurrent || !href ? 'current' : 'link'; if (isCurrent || !href) { return {label} ; } return {label} ; })}

; }; Long-running transactions on your database can cause deploy requests to fail. When you deploy a schema change, PlanetScale copies the table in the background so the original stays available. That copy needs a brief lock on the table: once at the start, and again as copying continues. The last step, [cutover](/docs/vitess/schema-changes/aggressive-cutover), needs a lock too. ## How to fix long-running transactions If Vitess is unable to get a lock on the table, it will fail the deploy. This is most commonly caused by a long-running transaction that is still open on the table. For example, if your app opens a transaction, updates the table, and then doesn't commit or rollback, Vitess will be unable to get a lock on the table. Having this query pattern in low volume is generally not a problem. But if you have a high volume of these queries, it can cause Vitess to not be able to get a lock on the table. To fix this, you need to: **Commit or rollback the transaction as soon as possible** ### External service calls Another common anti-pattern is to open a transaction, update the table, and then wait on additional API calls (such as calls to an external service). This can cause the transaction to be held open for a long time, and can prevent the deploy request from completing. In these cases, we recommend moving the external API calls to outside of the transaction. ## Additional tips * The [aggressive cutover setting](/docs/vitess/schema-changes/aggressive-cutover) only helps after the copy phase has finished. If your deploy request is stuck in the copy phase, this setting will not help. * If the change is [instantly deployable](/docs/vitess/schema-changes/deploy-requests#instant-deployments), Instant deploy skips the copy, so it doesn't need this lock. ## Need help? Get help from [the PlanetScale Support team](https://planetscale.com/contact?initial=support), or join our [Discord community](https://pscale.link/community) to see how others are using PlanetScale.