【问题标题】:pg_dump / pg_restore error with extension cube扩展多维数据集的 pg_dump / pg_restore 错误
【发布时间】:2020-08-25 19:41:13
【问题描述】:

由于公共架构中的一些扩展,我在转储和恢复我的一个数据库时遇到了问题。引发错误的扩展似乎是Cube 扩展或EarthDistance 扩展。这是我得到的错误:

pg_restore: [archiver (db)] Error from TOC entry 2983;
pg_restore: [archiver (db)] could not execute query: ERROR: type "earth" does not exist
LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth

QUERY: SELECT cube(cube(cube(earth()*cos(radians($1))*cos(radians($2))),earth()*cos(radians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
CONTEXT: SQL function "ll_to_earth" during inlining
   Command was: REFRESH MATERIALIZED VIEW public.locationsearch

我自己编写的一些函数也遇到了类似的不同问题,问题最终成为搜索路径,因此将这些函数的搜索路径明确设置为公开解决了我的问题。我对ll_to_earth 进行了同样的尝试,但似乎整个扩展都是问题所在。我真的不想尝试为pg_catalog 安装扩展程序,因为这似乎是一种糟糕的做法。

这是我典型的转储命令:

pg_dump -U postgres -h ipAddress -p 5432 -w -F t database > database.tar

接着是:

pg_restore -U postgres -h localhost -p 5432 -w -d postgres -C "database.tar"

包含数据的完整转储约为 4gb,但我尝试仅转储带有 -s-F p 的架构,有趣的是这是开始:

--
-- PostgreSQL database dump
--

-- Dumped from database version 12.2
-- Dumped by pg_dump version 12.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 xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

--
-- Name: cube; Type: EXTENSION; Schema: -; Owner: -
--

CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA public;


--
-- Name: EXTENSION cube; Type: COMMENT; Schema: -; Owner: 
--

COMMENT ON EXTENSION cube IS 'data type for multidimensional cubes';


--
-- Name: earthdistance; Type: EXTENSION; Schema: -; Owner: -
--

CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA public;


--
-- Name: EXTENSION earthdistance; Type: COMMENT; Schema: -; Owner: 
--

COMMENT ON EXTENSION earthdistance IS 'calculate great-circle distances on the surface of the Earth';

我想我很困惑......从逻辑上讲,这与我使用 tar 格式的情况不一样吗?我知道问题是当pg_restore 到达那个物化视图并尝试使用函数ll_to_earth(float8, float8) 它失败了,因为该函数不在其搜索路径中或尚未恢复,但不会这样表示扩展是首先要恢复的?可以解决吗?

这是我编写的脚本的一部分,它将在我的生产环境中转储数据库并每天在我的测试环境中恢复数据库,以便它们匹配。它工作了几个月,直到我开始使用这个扩展,我不知道如何纠正它。

【问题讨论】:

    标签: postgresql pg pg-dump pg-restore


    【解决方案1】:

    出于安全原因,pg_dumpsearch_path 设置为空,因此如果在没有架构限定的情况下引用它们,则只会找到系统架构 pg_catalog 中的对象。

    现在您的 SQL 函数使用数据类型 earth 而不使用架构(可能是 public),因此您会收到错误消息。

    您必须更改函数以使用限定名称(如 public.earth)作为扩展对象。或者,可能更好的是为函数修复search_path

    ALTER FUNCTION myfun SET search_path = public;
    

    无论如何这是个好主意,否则如果用户更改search_path,您的功能将停止工作。根据定义或使用函数的方式,这甚至可能构成安全问题(这就是 pg_dump 这样做的原因)。

    【讨论】:

    • 非常感谢,劳伦兹!这完美地解决了我的问题。
    猜你喜欢
    • 2013-05-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-11-28
    • 1970-01-01
    • 1970-01-01
    • 2011-01-06
    • 2020-07-05
    相关资源
    最近更新 更多