Re: Avoid orphaned objects dependencies, take 3

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-06-13T14:49:34Z
Lists: pgsql-hackers
On Fri, Jun 7, 2024 at 4:41 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> Do you still find the code hard to maintain with v9?

I don't think it substantially changes my concerns as compared with
the earlier version.

> > but we're not similarly careful about other operations e.g.
> > ConstraintSetParentConstraint is called by DefineIndex which calls
> > table_open(childRelId, ...) first, but there's no logic in DefineIndex
> > to lock the constraint.
>
> table_open(childRelId, ...) would lock any "ALTER TABLE <childRelId> DROP CONSTRAINT"
> already. Not sure I understand your concern here.

I believe this is not true. This would take a lock on the table, not
the constraint itself.

-- 
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