Horton

Re: Index functions and INDEX_CREATE_SKIP_BUILD

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Antonin Houska <ah@cybertec.at>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-02T07:54:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make relation-enumerating operations be security-restricted operations.

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