MIME-Version: 1.0
References: <CAHAc2jd=x-6hM=CoEYOaJ6ST5p-nGkTxDmh=PrwxacnkUp=31A@mail.gmail.com>
 <1164079167.6346688.1772982934392@mail.yahoo.com> <CAHAc2jeME7KPPP3TgP9qWC5LMTOs4gYTEJ1MBDwnj7J2EvJTdA@mail.gmail.com>
 <1656643760.2116109.1772994207524@mail.yahoo.com>
In-Reply-To: <1656643760.2116109.1772994207524@mail.yahoo.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Sun, 8 Mar 2026 18:08:01 -0400
Message-ID: <CAKAnmmKD2kxF6pD3c5eFhJZ+TMogRS9dHcMWbmiZs2Vn=XvZ0g@mail.gmail.com>
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17
 and Django's select_for_update()
To: felix.quintgz@yahoo.com
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000027e3f1064c8a8769"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmKD2kxF6pD3c5eFhJZ%2BTMogRS9dHcMWbmiZs2Vn%3DXvZ0g%40mail.gmail.com>
Precedence: bulk

--00000000000027e3f1064c8a8769
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 8, 2026 at 2:23=E2=80=AFPM <felix.quintgz@yahoo.com> wrote:

> What makes me suspect it's a lock on the parent table is the word
> "ShareLock" in the logs. A SELECT ... FOR UPDATE statement shouldn't plac=
e
> that type of lock on the table it's selecting.
>

This looks 100% like a normal, multi-row deadlock situation. The CONTEXT
shows it is a row-level problem:

CONTEXT: while locking tuple (7,15) in relation =E2=80=9Cpaiyroll_endpoint=
=E2=80=9D


The ShareLocks are on the transaction, because each backend is waiting for
the other to finish their transaction, and thus release the lock(s) it may
have.

If you implement Tom's suggestion, I think you will find that this is a
classic failing to lock the rows in the same order problem.

Cheers,
Greg

--00000000000027e3f1064c8a8769
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 8, 2026 at 2:23=
=E2=80=AFPM &lt;<a href=3D"mailto:felix.quintgz@yahoo.com">felix.quintgz@ya=
hoo.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">What makes me suspect it&#39;s a lock on the parent table is the wor=
d &quot;ShareLock&quot; in the logs. A SELECT ... FOR UPDATE statement shou=
ldn&#39;t place that type of lock on the table it&#39;s selecting.<br></blo=
ckquote></div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><=
div><br></div></div></div></div><div dir=3D"ltr">This looks 100% like a nor=
mal, multi-row deadlock situation. The CONTEXT shows it is a row-level prob=
lem:<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">CONTEX=
T: while locking tuple (7,15) in relation =E2=80=9Cpaiyroll_endpoint=E2=80=
=9D</blockquote><div><br></div><div>The ShareLocks are on the transaction, =
because each backend is waiting for the other to finish their transaction, =
and thus release the lock(s) it may have.</div><div><br></div><div>If you i=
mplement Tom&#39;s suggestion, I think you will find that this is a classic=
 failing to lock the rows in the same order problem.</div><div><br></div><d=
iv>Cheers,</div><div>Greg</div><div><br></div></div></div>

--00000000000027e3f1064c8a8769--