Re: Fix search_path for all maintenance commands

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>

To: Jeff Davis <pgsql@j-davis.com>

Cc: Nathan Bossart <nathandbossart@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>

Date: 2023-07-22T14:04:38Z

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 →

Fix search_path to a safe value during maintenance operations.
- 2af07e2f749a 17.0 landed
- 05e173735171 16.0 landed
Make relation-enumerating operations be security-restricted operations.
- a117cebd638d 15.0 cited

On Fri, Jul 21, 2023 at 03:32:43PM -0700, Jeff Davis wrote:
> Why do we switch to the table owner and use
> SECURITY_RESTRICTED_OPERATION in DefineIndex(), when we will switch in
> index_build (etc.) anyway?

Commit a117ceb added that, and it added some test cases that behaved
differently without that.

> Similarly, why do we switch in vacuum_rel(),
> when it doesn't matter for lazy vacuum and we will switch in
> cluster_rel() and do_analyze_rel() anyway?

It conforms to the "as soon as possible after locking the relation" coding
rule that commit a117ceb wrote into miscinit.c.  That provides future
proofing.