Question

在PostgreSQL 11上，我定期转储备份快照，有时将它们导入具有相同设置的开发系统中。没什么好看的：

# Dump
ps_dump -OU <user> <database> >dump.sql
# Restore
psql -U <user> -f dump.sql <database>

但是，还原时转储中的两个索引抛出错误。我将其简化为以下转储，删除了所有不相关的内容：

--
-- PostgreSQL database dump
--

-- Dumped from database version 11.2
-- Dumped by pg_dump version 11.2

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

--
-- Name: add_days(timestamp without time zone, integer, text); Type: FUNCTION; Schema: public; Owner: -
--

CREATE FUNCTION public.add_days(timestamp without time zone, integer, text DEFAULT 'Europe/Zurich'::text) RETURNS timestamp without time zone
    LANGUAGE sql IMMUTABLE
    SET search_path TO 'public', 'pg_temp'
    AS $_$
          SELECT (($1::timestamp AT TIME ZONE 'UTC' AT TIME ZONE $3 + INTERVAL '1 day' * $2) AT TIME ZONE $3)::timestamp
        $_$;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- Name: projects; Type: TABLE; Schema: public; Owner: -
--

CREATE TABLE public.projects (
    id integer NOT NULL,
    started_at timestamp without time zone,
    duration integer
);

--
-- Name: ended_at(public.projects); Type: FUNCTION; Schema: public; Owner: -
--

CREATE FUNCTION public.ended_at(public.projects) RETURNS timestamp without time zone
    LANGUAGE sql STABLE
    AS $_$
          SELECT add_days($1.started_at, $1.duration)
        $_$;

--
-- Name: index_projects_on_ended_at; Type: INDEX; Schema: public; Owner: -
--

CREATE INDEX index_projects_on_ended_at ON public.projects USING btree (public.ended_at(projects.*));

还原此转储会产生以下错误：

psql:dumped.sql:60: ERROR:  function add_days(timestamp without time zone, integer) does not exist
LINE 2:           SELECT add_days($1.started_at, $1.duration)
                     ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
QUERY:
      SELECT add_days($1.started_at, $1.duration)

CONTEXT:  SQL function "ended_at" during inlining

以下内容解决了该问题：前缀为add_days的架构如下：

CREATE FUNCTION public.ended_at(public.projects) RETURNS timestamp without time zone
    LANGUAGE sql STABLE
    AS $_$
          SELECT public.add_days($1.started_at, $1.duration)
        $_$;

案件已结案？不完全的。我想了解这里的问题。

我想，除非有明确的模式前缀，否则pg_dump生成的行SELECT pg_catalog.set_config('search_path', '', false);会阻止找到add_days。

但是，为什么以下替代方法（添加search_path）不起作用？

CREATE FUNCTION public.ended_at(public.projects) RETURNS timestamp without time zone
    LANGUAGE sql STABLE
    SET search_path TO 'public', 'pg_temp'
    AS $_$
          SELECT add_days($1.started_at, $1.duration)
        $_$;

这会触发完全不同的错误：

psql:dumped.sql:58: ERROR:  functions in index expression must be marked IMMUTABLE

好的，现在我很困惑。有人可以告诉我这是怎么回事吗？

Answer 1

这里有两个不同的问题。

为什么在还原转储时出现错误？

此问题是由this补丁引起的，该补丁修复了PostgreSQL的安全性问题。

在进行此更改之前，pg_dump / pg_restore会将search_path设置为以下形式：
```
SET search_path = dumped_schema, pg_catalog;
```
问题在于，索引定义（及其他地方）中使用的任何函数或运算符都将首先在dumped_schema中进行搜索。

在还原过程中，恶意用户可以使用该用户权限以超级用户权限执行其功能。

您已经想出了解决问题的方法。

这确实很烦人，但是鉴于到目前为止，您的功能仍受当前search_path设置（任何人都可以使用简单的SET命令进行更改）的摆布，我将其视为自身的进步。
为什么对功能上的SET search_path不起作用？

这里的问题是，索引中使用的任何函数都必须为IMMUTABLE（无论如何，必须为相同的参数返回相同的结果），否则索引可能会损坏。但是，ended_at是STABLE，而不是IMMUTABLE。

问题在您的原始设置中被“掩盖”，因为PostgreSQL可以内联函数，即用其定义替换函数调用。现在add_days 被标记为IMMUTABLE，就可以了。

在函数上设置search_path后，将无法再内联函数，因此现在您将收到错误消息。

我说你也应该将ended_at声明为IMMUTABLE。

导入包含索引中使用的函数的SQL转储时出错

1 个答案: