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