Re: How to investigate deadlocks - Mailing list pgsql-general

From Laurenz Albe
Subject Re: How to investigate deadlocks
Date
Msg-id d0f95718a0e015feb598ba4b8e25eb90f01c9217.camel@cybertec.at
Whole thread Raw
In response to How to investigate deadlocks  (Matthias Apitz <guru@unixarea.de>)
List 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
process18187. 
>         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



pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Cancelling "vacuum full" in single user mode?
Next
From: Tom Lane
Date:
Subject: Re: How to investigate deadlocks