public inbox for [email protected]help / color / mirror / Atom feed
Table-Level Locks and Transactions 4+ messages / 3 participants [nested] [flat]
* Table-Level Locks and Transactions @ 2021-12-09 01:07 Greg Rychlewski <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Greg Rychlewski @ 2021-12-09 01:07 UTC (permalink / raw) To: [email protected] Hi, I'm curious to understand when table-level locks are released by one transaction to use in another. For instance, say I have the following transaction, where index1 and index2 both belong to the same table. BEGIN; DROP INDEX index1; CREATE INDEX index2; COMMIT; This transaction acquires an ACCESS EXCLUSIVE lock during the DROP INDEX step and then acquires a SHARE lock during the CREATE INDEX step. I understand that there will be no conflicts between the statements in this transaction, but I'm wondering if an outside transaction will think that the table has an ACCESS EXCLUSIVE lock until this entire transaction is completed. Thanks ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Table-Level Locks and Transactions @ 2021-12-09 10:33 Simon Riggs <[email protected]> parent: Greg Rychlewski <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Simon Riggs @ 2021-12-09 10:33 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] On Thu, 9 Dec 2021 at 01:07, Greg Rychlewski <[email protected]> wrote: > > I'm curious to understand when table-level locks are released by one transaction to use in another. At the end of transaction. > For instance, say I have the following transaction, where index1 and index2 both belong to the same table. > > BEGIN; > DROP INDEX index1; > CREATE INDEX index2; > COMMIT; > > This transaction acquires an ACCESS EXCLUSIVE lock during the DROP INDEX step and then acquires a SHARE lock during the CREATE INDEX step. > > I understand that there will be no conflicts between the statements in this transaction, but I'm wondering if an outside transaction will think that the table has an ACCESS EXCLUSIVE lock until this entire transaction is completed. No, just index1, but the SHARE lock will prevent writes. Have you thought about using DROP INDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY? If in doubt, try it. Look at pg_locks. -- Simon Riggs http://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Table-Level Locks and Transactions @ 2021-12-09 11:47 Laurenz Albe <[email protected]> parent: Simon Riggs <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Laurenz Albe @ 2021-12-09 11:47 UTC (permalink / raw) To: Simon Riggs <[email protected]>; [email protected]; +Cc: [email protected] On Thu, 2021-12-09 at 10:33 +0000, Simon Riggs wrote: > On Thu, 9 Dec 2021 at 01:07, Greg Rychlewski <[email protected]> wrote: > > > > I'm curious to understand when table-level locks are released by one transaction to use in another. > > At the end of transaction. > > > For instance, say I have the following transaction, where index1 and index2 both belong to the same table. > > > > BEGIN; > > DROP INDEX index1; > > CREATE INDEX index2; > > COMMIT; > > > > This transaction acquires an ACCESS EXCLUSIVE lock during the DROP INDEX step and then acquires a SHARE lock during the CREATE INDEX step. > > > > I understand that there will be no conflicts between the statements in this transaction, > > but I'm wondering if an outside transaction will think that the table has an ACCESS EXCLUSIVE > > lock until this entire transaction is completed. > > No, just index1, but the SHARE lock will prevent writes. Not sure what you mean by that, but the ACCESS EXCLUSIVE lock from DROP INDEX will be held until the end of the transaction. > Have you thought about using DROP INDEX CONCURRENTLY and CREATE INDEX > CONCURRENTLY? These cannot be used in a transaction, however. > If in doubt, try it. Look at pg_locks. +1 Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Table-Level Locks and Transactions @ 2021-12-09 12:47 Simon Riggs <[email protected]> parent: Laurenz Albe <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Simon Riggs @ 2021-12-09 12:47 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected] On Thu, 9 Dec 2021 at 11:47, Laurenz Albe <[email protected]> wrote: > > Have you thought about using DROP INDEX CONCURRENTLY and CREATE INDEX > > CONCURRENTLY? > > These cannot be used in a transaction, however. True, but they don't need to be for this case. If this is the same index, look at REINDEX CONCURRENTLY. -- Simon Riggs http://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2021-12-09 12:47 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-12-09 01:07 Table-Level Locks and Transactions Greg Rychlewski <[email protected]> 2021-12-09 10:33 ` Simon Riggs <[email protected]> 2021-12-09 11:47 ` Laurenz Albe <[email protected]> 2021-12-09 12:47 ` Simon Riggs <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox