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