标签: pg-dump

我使用自制软件安装了Postgres 9.0.x,但由于缺少某些模块,我使用以下方法将其删除:

brew uninstall postgres

并从http://www.enterprisedb.com/downloads/postgres-postgresql-downloads安装了Postgres 9.1.3 .

现在我遇到了一个问题 - 在pg_dump上有两个不同的版本 - 9.0.5和9.1.3和9.0.5是默认版本.

有没有办法将9.1.3版本设置为pg_dump的默认版本？

我有两个数据库在不同时区的不同服务器上运行.有几个表包含timestamp with timezone.

我需要从一个数据库转储数据,并使用正确的时间戳和正确的时区将其导入另一个数据库.

我使用以下命令来转储数据:

pg_dump -a DB_NAME > dump.sql

我看到数据采用旧时间戳和时区格式: 2013-11-29 14:30:00+02

然后我使用命令到另一台服务器来恢复转储:

psql -d DB_NAME -f dump.sql

我看到时间戳和时区来自旧服务器 - 我认为这是正常的.

然后我尝试在dump.sql的开头添加以下命令

SET timezone ...

但仍然行不通.:(

这是一次性操作.一旦传输数据不需要同步.有没有办法使用pg_dump和pg_restore或类似的方式进行此类转换？

omnia@ubuntu:~$ psql --version
psql (PostgreSQL) 9.3.4
omnia@ubuntu:~$ pg_dump --version
pg_dump (PostgreSQL) 9.2.8
omnia@ubuntu:~$ dpkg -l | grep pg
ii  gnupg                            1.4.11-3ubuntu2.5                 GNU privacy guard - a free PGP replacement
ii  gpgv                             1.4.11-3ubuntu2.5                 GNU privacy guard - signature verification tool
ii  libgpg-error0                    1.10-2ubuntu1                     library for common error values and messages in GnuPG components
ii  libpq5                           9.3.4-1.pgdg60+1                  PostgreSQL C client library
ii  pgdg-keyring                     2013.2                            keyring for apt.postgresql.org
ii  postgresql-9.2                   9.2.8-1.pgdg60+1                  object-relational SQL database, version 9.2 server
ii  postgresql-9.3                   9.3.4-1.pgdg60+1                  object-relational SQL database, …

在数据库上进行备份时遇到问题包含大约50个模式,每个模式有大约100个表.

pg_dump抛出以下错误表明要增加max_locks_per_transaction.

pg_dump: WARNING:  out of shared memory
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.
pg_dump: The command was: SELECT tableoid, oid, prsname, prsnamespace, prsstart::oid, prstoken::oid, prsend::oid, prsheadline::oid, prslextype::oid FROM pg_ts_parser

更新max_locks_per_transaction到256 in postgresql.conf并没有解决问题.

有没有可能导致这个问题的可能性？

编辑:(2016年5月7日)

Postgresql版本= 9.1

操作系统= Ubuntu 14.04.2 LTS

shared_buffersin postgresql.conf= 2GB

编辑:(2016年5月9日)

我的postgres.conf

maintenance_work_mem = 640MB
wal_buffers = 64MB
shared_buffers = 2GB
max_connections = 100 …

问题：使用PSQLpg_dump和pg_restore在Python脚本，并使用该subprocess模块。

背景：我使用python 2.7来自本地主机（即Ubuntu 14.04.5 LTS）的以下脚本在 PSQL 服务器（即PostgreSQL 9.4.11）中创建表的备份，并将其恢复到Ubuntu 16.04.2 LTS较新版本的 PSQL 服务器（即PostgreSQL 9.6.2）中的远程主机（即）。

#!/usr/bin/python

from subprocess import PIPE,Popen

def dump_table(host_name,database_name,user_name,database_password,table_name):

    command = 'pg_dump -h {0} -d {1} -U {2} -p 5432 -t public.{3} -Fc -f /tmp/table.dmp'\
    .format(host_name,database_name,user_name,table_name)

    p = Popen(command,shell=True,stdin=PIPE)

    return p.communicate('{}\n'.format(database_password))

def restore_table(host_name,database_name,user_name,database_password):

    command = 'pg_restore -h {0} -d {1} -U {2} < /tmp/table.dmp'\
    .format(host_name,database_name,user_name)

    p = Popen(command,shell=True,stdin=PIPE)

    return p.communicate('{}\n'.format(database_password))

def …

我正在使用“ pg_dump database_name> backup.sql”对postgres数据库进行转储。稍后，我将对原始数据库（数据库名称）进行一些修改，然后从备份文件（backup.sql）还原数据。但是结果是数据库没有恢复到原始状态，而是将原始数据添加到修改后的数据（修改后的+原始）中，我只希望它恢复到原始状态，我是否应该删除所有从备份文件还原数据库之前，先从数据库中还原数据，因为它提供了数据库的原始状态。还是有其他方法可以做到这一点？

是否可以查询 db 中有多少多版本行？

我们想测量pg_dump对生产数据库的影响，并在需要时暂停它：它是否创建了太多多版本行？

提前致谢

pg_dump --table=export_view --data-only --column-inserts mydb > export_view.sql

pg_dump (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg18.04+1)

将 PostgreSQL 表中的特定行作为 INSERT SQL 脚本导出，postgresql 文档 ( https://www.postgresql.org/docs/10/app-pgdump.html ) 表明可以pg_dump从带有--table标志的视图中导出。如果我直接从表中导出，我会得到预期的结果（即，数据被导出）。如果我从 psql 中的视图中选择，我会得到预期的结果。但是，无论我是创建视图还是物化视图，然后尝试 和pg_dump，我都只得到正常的pg_dump标题而没有数据。评论者（/sf/users/142529481/）在上述 SO 问题中似乎也遇到了同样的问题，但没有给出解决方案。

如果我CREATE TABLE blah AS SELECT x, y, z FROM MYTABLE那么我可以很好地导出。如果我CREATE VIEW blah AS SELECT x, y, z FROM MYTABLE那么出口是空的。

我究竟做错了什么？

迁移我的开发数据库后，我无法运行rails db:test:prepare.

我的应用程序使用该db/structure.sql文件来更新测试数据库：

# config/application.rb

config.active_record.schema_format = :sql

当我运行rails db:migrate（也运行db:structure:dump）时，我db/structure.sql的更新。不幸的是，它现在在更新后在顶部附近包含此行：

CREATE SCHEMA public;

这将在加载到已经包含public模式的数据库中时爆炸。

我可以手动更新该行并成功加载 SQL 转储：

CREATE SCHEMA IF NOT EXISTS public;

...但我不想每次都这样做。

我希望在db/structure.sql运行时从 SQL 转储成功构建测试数据库，rails db:test:prepare因为 SQL 转储不应尝试创建public模式。

我正在尝试仅使用 PostgreSQL 数据库转储数据pg_dump，然后将这些数据恢复到另一个数据库中。但是使用此工具生成 sql 脚本也会在输出文件中添加一些注释和设置。

运行此命令：

pg_dump --column-inserts --data-only my_db > my_dump.sql

我得到类似的东西：

--
-- PostgreSQL database dump
--

-- Dumped from database version 8.4.22
-- Dumped by pg_dump version 10.8 (Ubuntu 10.8-0ubuntu0.18.04.1)

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

-- …