Re: pgsql: Fix search_path to a safe value during maintenance operations. - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgsql: Fix search_path to a safe value during maintenance operations.
Date
Msg-id 202403051619.jiuwd3ec4jmi@alvherre.pgsql
Whole thread Raw
Responses Re: pgsql: Fix search_path to a safe value during maintenance operations.
List pgsql-hackers
On 2024-Mar-05, Jeff Davis wrote:

> Fix search_path to a safe value during maintenance operations.
> 
> While executing maintenance operations (ANALYZE, CLUSTER, REFRESH
> MATERIALIZED VIEW, REINDEX, or VACUUM), set search_path to
> 'pg_catalog, pg_temp' to prevent inconsistent behavior.
> 
> Functions that are used for functional indexes, in index expressions,
> or in materialized views and depend on a different search path must be
> declared with CREATE FUNCTION ... SET search_path='...'.

This appears to have upset the sepgsql tests.  In buildfarm member
rhinoceros there's now a bunch of errors like this

 ALTER TABLE regtest_table_4
       ADD CONSTRAINT regtest_tbl4_con EXCLUDE USING btree (z WITH =);
+LOG:  SELinux: allowed { search } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
tcontext=unconfined_u:object_r:sepgsql_schema_t:s0tclass=db_schema name="regtest_schema" permissive=0
 
+LOG:  SELinux: allowed { search } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
tcontext=system_u:object_r:sepgsql_schema_t:s0tclass=db_schema name="public" permissive=0
 

in its ddl.sql test.  I suppose this is just the result of the internal
change of search_path.  Maybe the thing to do is just accept the new
output as expected.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos (bis) / con todos los humanos acabaré ¡acabaré! (Bender)



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: un-revert the MAINTAIN privilege and the pg_maintain predefined role
Next
From: "Amonson, Paul D"
Date:
Subject: RE: Popcount optimization using AVX512