Re: Avoid orphaned objects dependencies, take 3

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Roman Eskin <r(dot)eskin(at)arenadata(dot)io>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: 2026-06-04 17:03:22
Message-ID: 02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2026-06-01 at 09:21 +0000, Bertrand Drouvot wrote:
> The tracking array lives in a dedicated AclCheckTrackContext memory
> context
> (child of TopMemoryContext). The context is reset at the start of
> each
> top-level utility statement, which frees all prior allocations and
> provides
> clean lifetime management.
>
> Recording is gated by aclcheck_tracking_active, which is set to true
> only
> during top-level utility statement execution. This ensures DML and
> queries pay
> no cost. The flag is cleared both at normal completion of
> ProcessUtility and in
> AbortTransaction to handle the error path.

This could use some better high-level comments in the code. Something
like:

"DDL performs ACL checks on referenced objects before acquiring a lock
on them. The lock is acquired much later, when recording dependencies.
Track the ACL checks, so that we can re-check them after acquiring the
lock. XXX: consider refactoring so that we perform the name lookup,
acquire the lock, and check ACLs all in unison, like
RangeVarGetRelidExtended()."

Assuming I understand correctly.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2026-06-04 17:14:34 Re: analyze-in-stages post upgrade questions
Previous Message Tristan Partin 2026-06-04 16:59:00 Re: Add pg_stat_kind_info system view