Michael Paquier <[email protected]> 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
