Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: felix(dot)quintgz(at)yahoo(dot)com, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
Date: 2026-03-08 18:03:04
Message-ID: 55c5a250a9026af4132d90954c081b11d5752522.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2026-03-08 at 15:15 +0000, felix(dot)quintgz(at)yahoo(dot)com wrote:
> This is pure speculation.
> It's possible that using SELECT FOR UPDATE also locks the rows in the parent tables referenced in the field list.
> I believe this happened in older versions of PostgreSQL.

I thought about that too, but since both updates affect the same table,
the foreign key would have to reference the table itself.

You are right that a SELECT ... FOR UPDATE will place a lock on any
referenced row (and FOR UPDATE will probably use a lock that is too
strong!), but those locks would still be SHARE locks, which can
coexist.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message felix.quintgz 2026-03-08 18:23:27 Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
Previous Message Shaheed Haque 2026-03-08 16:19:22 Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()