From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
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 16:38:21 |
Message-ID: | CAHyXU0wK9NVMv+JRBYk26HqeDXn=5XoNCdBB=MC81A9KjRz6Tg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
On Thu, Mar 17, 2022 at 2:52 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zheng Li | 2022-03-18 17:25:09 | Re: Support logical replication of DDLs |
Previous Message | Japin Li | 2022-03-18 10:19:38 | Re: Support logical replication of DDLs |
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Midgley | 2022-03-18 19:58:02 | Re: PostgreSQL trigger on user logon |
Previous Message | Kevin Tu | 2022-03-18 14:46:35 | PostgreSQL trigger on user logon |