Re: ERROR: deadlock detected

From: Torsten Förtsch <tfoertsch123(at)gmail(dot)com>
To: Matthias Apitz <guru(at)unixarea(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: deadlock detected
Date: 2023-02-07 12:16:13
Message-ID: CAKkG4_=gty0EE1Xts88yKduKJyR=fa_5VGOkD=jEQu6RFmHg_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Feb 7, 2023 at 12:47 PM Matthias Apitz <guru(at)unixarea(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Giovanni Biscontini 2023-02-07 13:19:49 Re: PostgreSQL
Previous Message vignesh C 2023-02-07 12:05:10 Re: Support logical replication of DDLs