ERROR: deadlock detected

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 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

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