Horton
Menu

Re: Avoid orphaned objects dependencies, take 3

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-05-19T18:07:34Z
Lists: pgsql-hackers 
On Mon, May 19, 2025 at 1:02 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I'm not sure if you intended it this way, but using "clever" here
> suggests that it's an unusual trick. But isn't that the kind of thing
> heavyweight locks are for?
>
> FWIW, a lock while recording a dependency would not be surprising to
> me. Assuming that heavyweight locks are the right approach, the locks
> need to be taken somewhere. And expecting all the callers to get it
> right seems error-prone.

I agree with that, but I think that it may also be error-prone to
assume that it's OK to acquire heavyweight locks on other catalog
objects at any place in the code where we record a dependency. I will
not be surprised at all if that turns out to have some negative
consequences. For example, I think it might result in acquiring the
locks on those other objects at a subtly wrong time (leading to race
conditions) or acquiring two locks on the same object with different
lock modes where we should really only acquire one. I'm all in favor
of solving this problem using heavyweight locks, but I think that
implicitly acquiring them as a side effect of recording dependencies
feels too surprising.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid orphaned objects dependencies

  2. Don't try to record dependency on a dropped column's datatype