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.