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