Thread: ERROR: deadlock detected
We saw the following message in the file postgres-serverlog.error:
2023-01-24 17:16:16.578 CET [17468] ERROR: deadlock detected
2023-01-24 17:16:16.578 CET [17468] DETAIL: Process 17468 waits for ShareLock on transaction 90776649; blocked by
process17724.
Process 17724 waits for ShareLock on transaction 90776650; blocked by process 17468.
Process 17468: fetch hc_d03geb
Process 17724: fetch hc_d02ben
2023-01-24 17:16:16.578 CET [17468] HINT: See server log for query details.
2023-01-24 17:16:16.578 CET [17468] CONTEXT: while locking tuple (948,45) in relation "d03geb"
2023-01-24 17:16:16.578 CET [17468] STATEMENT: fetch hc_d03geb
There are no messages in the serverlog itself and in our application
log files. What can we do to get to more information (may be next time)?
The process numbers are internal ones of the PostgreSQL server and not
the Linux PID, correct?
Thanks
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
On Tue, Feb 7, 2023 at 12:47 PM Matthias Apitz <guru@unixarea.de> wrote:
We saw the following message in the file postgres-serverlog.error:
2023-01-24 17:16:16.578 CET [17468] ERROR: deadlock detected
2023-01-24 17:16:16.578 CET [17468] DETAIL: Process 17468 waits for ShareLock on transaction 90776649; blocked by process 17724.
Process 17724 waits for ShareLock on transaction 90776650; blocked by process 17468.
Process 17468: fetch hc_d03geb
Process 17724: fetch hc_d02ben
2023-01-24 17:16:16.578 CET [17468] HINT: See server log for query details.
2023-01-24 17:16:16.578 CET [17468] CONTEXT: while locking tuple (948,45) in relation "d03geb"
2023-01-24 17:16:16.578 CET [17468] STATEMENT: fetch hc_d03geb
The process numbers are internal ones of the PostgreSQL server and not
the Linux PID, correct?
If you run this on linux, then the process numbers are the PIDs of the postgres backend processes. They are not the PIDs of your application but what would be returned by `pg_backend_pid()` or what you see in `pg_stat_activity`.
This piece (948,45) is the CTID of the tuple where the deadlock occurred.
If you really want to find out how the deadlock came about, you could use pg_waldump. You search for the transaction ids and figure out what they were doing.
Torsten
On Tue, 2023-02-07 at 12:46 +0100, Matthias Apitz wrote: > We saw the following message in the file postgres-serverlog.error: > > 2023-01-24 17:16:16.578 CET [17468] ERROR: deadlock detected > 2023-01-24 17:16:16.578 CET [17468] DETAIL: Process 17468 waits for ShareLock on transaction 90776649; blocked by process17724. > Process 17724 waits for ShareLock on transaction 90776650; blocked by process 17468. > Process 17468: fetch hc_d03geb > Process 17724: fetch hc_d02ben > 2023-01-24 17:16:16.578 CET [17468] HINT: See server log for query details. > 2023-01-24 17:16:16.578 CET [17468] CONTEXT: while locking tuple (948,45) in relation "d03geb" > 2023-01-24 17:16:16.578 CET [17468] STATEMENT: fetch hc_d03geb > > There are no messages in the serverlog itself and in our application > log files. What can we do to get to more information (may be next time)? There will be a message in the server log, unless you set "log_min_messages" to "fatal" or higher. > The process numbers are internal ones of the PostgreSQL server and not > the Linux PID, correct? PostgreSQL uses the process number of the backend process on the database server as identifier of a session, so it is indeed an operatin system process ID. Yours, Laurenz Albe