Обсуждение: How to explicitly lock and unlock tables in pgsql?
Table locks present a barrier for progressing queries.
How to explicitly lock and unlock tables in pgsql, so that we can guarantee the progress of running scripts?
Regards,
David
Em qua., 16 de mar. de 2022 às 17:30, Shaozhong SHI <shishaozhong@gmail.com> escreveu:
Table locks present a barrier for progressing queries.How to explicitly lock and unlock tables in pgsql, so that we can guarantee the progress of running scripts?Regards,David
| |||||||||||
| |||||||||||
On Wed, 2022-03-16 at 20:30 +0000, Shaozhong SHI wrote: > Table locks present a barrier for progressing queries. > > How to explicitly lock and unlock tables in pgsql, so that we can guarantee the progress of running scripts? You cannot unlock tables except by ending the transaction which took the lock. The first thing you should do is to make sure that all your database transactions are short. Also, you should nevr explicitly lock tables. Table locks are taken automatically by the SQL statements you are executing. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
On Thu, Mar 17, 2022 at 2:52 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > On Wed, 2022-03-16 at 20:30 +0000, Shaozhong SHI wrote: > > Table locks present a barrier for progressing queries. > > > > How to explicitly lock and unlock tables in pgsql, so that we can guarantee the progress of running scripts? > > You cannot unlock tables except by ending the transaction which took the lock. > > The first thing you should do is to make sure that all your database transactions are short. > > Also, you should nevr explicitly lock tables. Table locks are taken automatically > by the SQL statements you are executing. Isn't that a bit of overstatement? LOCK table foo; Locks the table, with the benefit you can choose the lockmode to decide what is and is not allowed to run after you lock it. The main advantage vs automatic locking is preemptively blocking things so as to avoid deadlocks. merlin
On Fri, 2022-03-18 at 11:38 -0500, Merlin Moncure wrote: > > Also, you should nevr explicitly lock tables. Table locks are taken automatically > > by the SQL statements you are executing. > > Isn't that a bit of overstatement? > LOCK table foo; > > Locks the table, with the benefit you can choose the lockmode to > decide what is and is not allowed to run after you lock it. The main > advantage vs automatic locking is preemptively blocking things so as > to avoid deadlocks. Yes, that was an overstatement. But I find that 90% of the time when people explicitly lock a table it is not the correct solution. Yours, Laurenz Albe