Обсуждение: Index functions and INDEX_CREATE_SKIP_BUILD

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

Which index functions can be called if index_create() receives the
INDEX_CREATE_SKIP_BUILD flag?

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com

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

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

On Tue, Dec 02, 2025 at 09:07:54AM +0100, Antonin Houska wrote:
> 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.

See commit a117cebd638d, particularly the test case in privileges.sql
that this commit has added with a REINDEX CONCURRENTLY at the bottom.
You should see a function execution with an assertion failure if you
attempt to remove the stack you are mentioning..
--
Michael