From: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: How to investigate deadlocks |
Date: | 2023-10-02 11:39:00 |
Message-ID: | 20c3aadc-e589-c601-c2a7-0ca89a7cec66@a-kretschmer.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Am 02.10.23 um 13:27 schrieb Matthias Apitz:
> Hello,
>
> One of our clients running our LMS on top of PostgreSQL 13.1 created a
> ticket with these messages:
>
> 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
> 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLock on transaction 150396154; blocked by process 18187.
> Process 18187 waits for ShareLock on transaction 150396155; blocked by process 18117.
> Process 18117: fetch hc_d03geb
> Process 18187: fetch hc_d02ben
> 2023-09-30 16:50:50.951 CEST [18117] HINT: See server log for query details.
> 2023-09-30 16:50:50.951 CEST [18117] CONTEXT: while locking tuple (38,57) in relation "d03geb"
> 2023-09-30 16:50:50.951 CEST [18117] STATEMENT: fetch hc_d03geb
>
> The shown PIDs for sure are the ones of the Pos backend proc (on Linux).
> Is there any chance to investigate it further?
please also check
https://www.cybertec-postgresql.com/en/postgresql-understanding-deadlocks/
Andreas
--
Andreas Kretschmer
Technical Account Manager (TAM)
www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Colin 't Hart | 2023-10-02 12:38:32 | Cancelling "vacuum full" in single user mode? |
Previous Message | Andreas Kretschmer | 2023-10-02 11:36:02 | Re: How to investigate deadlocks |