Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Dec 02, 2025 at 08:18:48AM +0100, Antonin Houska wrote:
> > In ReindexRelationConcurrently(), the call of index_concurrently_create_copy()
> > is enclosed in
> >
> > /*
> > * Switch to the table owner's userid, so that any index functions are
> > * run as that user. Also lock down security-restricted operations
> > * and arrange to make GUC variable changes local to this command.
> > */
> > GetUserIdAndSecContext(&save_userid, &save_sec_context);
> > SetUserIdAndSecContext(heapRel->rd_rel->relowner,
> > save_sec_context | SECURITY_RESTRICTED_OPERATION);
> > save_nestlevel = NewGUCNestLevel();
> >
> > and
> >
> > /* Roll back any GUC changes executed by index functions */
> > AtEOXact_GUC(false, save_nestlevel);
> >
> > /* Restore userid and security context */
> > SetUserIdAndSecContext(save_userid, save_sec_context);
>
> Yes.
>
> > Which index functions can be called if index_create() receives the
> > INDEX_CREATE_SKIP_BUILD flag?
>
> What do you mean here? Are you seeing an issue with that, or are you
> asking about a concept that would be introduced by a different patch?
I'm just wondering if these measures regarding GUCs and security context are
necessary at this place. I think that no index functions should be called if
we only create the catalog entry for the index, but I may be mistaken.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
