| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | d(dot)koval(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18498: Locking a table from a trigger (with using two sessions) causes a deadlock: the bug or the feature? |
| Date: | 2024-06-07 09:02:47 |
| Message-ID: | CAApHDvpXSQ5-=G-bCTYCVNr6EFwdLHJt5ydrN8X14SJds0VzYA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, 7 Jun 2024 at 20:58, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> s1: create table t ();
> s1: begin;
> s2: begin;
> s1: lock table t in access share mode;
> s2: lock table t in access share mode;
> s1: lock table t in access exclusive mode;
> s2: lock table t in access exclusive mode; -- deadlock
>
> Isn't this more or less the same as what's going on in your scenario?
I didn't explain why this needs to happen... s1 can't get the AEL on
"t" because it's blocked by s2's share lock. Subsequently, s2 then
must wait on s1's AEL request and that creates a deadlock cycle that
needs to be broken.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2024-06-07 09:10:44 | Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption |
| Previous Message | David Rowley | 2024-06-07 08:58:43 | Re: BUG #18498: Locking a table from a trigger (with using two sessions) causes a deadlock: the bug or the feature? |