Horton
Menu

Re: Avoid orphaned objects dependencies, take 3

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.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-21T17:17:58Z
Lists: pgsql-hackers 
On Wed, 2025-05-21 at 12:55 -0400, Robert Haas wrote:
> > ...like generate_partition_qual() taking a lock on the parent or
> > CheckAttributeType() taking a lock on the typrelid...
> 
> To me, relation_open() feels like the kind of operation that I would
> expect to take a lock. If I open something, I must have acquired some
> resource on it that I will then use for a while before closing the
> object.

Of course relation_open() takes a lock, but sometimes relation_open()
is hidden in the call stack below other functions where it's not so
obvious.

> 
> Yeah, that's not a terrible idea. I still like the idea I thought
> Bertrand was pursuing, namely, to take no lock in
> recordDependencyOn()
> but assert that the caller has previously acquired one. However, we
> could still do the Assert() check with this design when NoLock is
> passed, so I think this is a reasonable alternative to that design.

I'd have to see the patch to see whether I liked the end result. But
I'm guessing that involves a lot of non-mechanical changes in the call
sites, and also relies on test coverage for all of them.

Regards,
	Jeff Davis

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