Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update() - Mailing list pgsql-general

From Laurenz Albe
Subject Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
Date
Msg-id 55c5a250a9026af4132d90954c081b11d5752522.camel@cybertec.at
Whole thread Raw
In response to Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()  (felix.quintgz@yahoo.com)
List pgsql-general
On Sun, 2026-03-08 at 15:15 +0000, felix.quintgz@yahoo.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



pgsql-general by date:

Previous
From: Shaheed Haque
Date:
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()
Next
From: felix.quintgz@yahoo.com
Date:
Subject: Re: Unexpected deadlock across two separate rows, using Postgres 17 and Django's select_for_update()