From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Matthias Apitz <guru(at)unixarea(dot)de>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: How to investigate deadlocks |
Date: | 2023-10-02 14:01:48 |
Message-ID: | d0f95718a0e015feb598ba4b8e25eb90f01c9217.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2023-10-02 at 13:27 +0200, Matthias Apitz wrote:
> One of our clients running our LMS on top of PostgreSQL 13.1 created a
> ticket with these messages:
>
> 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
> 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLock on transaction 150396154; blocked by process 18187.
> Process 18187 waits for ShareLock on transaction 150396155; blocked by process 18117.
> Process 18117: fetch hc_d03geb
> Process 18187: fetch hc_d02ben
> 2023-09-30 16:50:50.951 CEST [18117] HINT: See server log for query details.
> 2023-09-30 16:50:50.951 CEST [18117] CONTEXT: while locking tuple (38,57) in relation "d03geb"
> 2023-09-30 16:50:50.951 CEST [18117] STATEMENT: fetch hc_d03geb
>
> The shown PIDs for sure are the ones of the Pos backend proc (on Linux).
> Is there any chance to investigate it further?
See the line:
HINT: See server log for query details.
Other than that, it is difficult to figure out the exact cause of a deadlock.
You need to know all the statements that were run in these transactions,
which probably requires deeper knowledge of the application.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-10-02 14:16:18 | Re: How to investigate deadlocks |
Previous Message | Laurenz Albe | 2023-10-02 13:59:41 | Re: Cancelling "vacuum full" in single user mode? |