From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Shaozhong SHI <shishaozhong(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: How to explicitly lock and unlock tables in pgsql? |
Date: | 2022-03-18 22:48:41 |
Message-ID: | 3cc08f35825c14458c4cd345ef449211d37ddc49.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2022-03-18 23:33:29 | Re: Support logical replication of DDLs |
Previous Message | Zheng Li | 2022-03-18 17:29:07 | Re: Support logical replication of DDLs |
From | Date | Subject | |
---|---|---|---|
Next Message | Jian He | 2022-03-25 04:46:17 | the order of operator computation |
Previous Message | Steve Midgley | 2022-03-18 19:58:02 | Re: PostgreSQL trigger on user logon |