John Powell's questions

我正在尝试将一些表从 9.5 beta 2 转储到 9.4.4 服务器。我使用的命令形式是相当标准的：

pg_dump -t table dbname | psql -h hostname -d dbname

我正在使用 Postgres 用户，我意识到这可能并不理想，但因为它们都是只有我使用的开发数据处理框，并且与随后的错误有关。最初，我得到了错误

错误：无法识别的配置参数“row_security”

这是预期的，因为这个功能是 9.5 中的新功能，而且，是的，我意识到在不同 Postgres 版本之间使用 pg_dump 是不可取的，但是，遗憾的是，这是不可避免的，因为我遇到了一个非常模糊的错误，并且需要移动一个大的静态数据量一次。

因此，使用这个可怕的 hack 删除 row_security 错误，并在第一个错误时打开 stop：

pg_dump -t tablemame dbname |sed 's/SET row_security = off;//'|
psql -v ON_ERROR_STOP=1 -h hostname -d dbname

我现在得到：

错误：创建“pg_catalog.tablename”的权限被拒绝 详细信息：当前不允许修改系统目录

虽然可能不希望使用 Postgres 用户/角色，但我的理解是不应该存在这种性质的权限问题。我愿意接受任何建议，记住这是一次性操作，并且这些是未连接到任何实时服务的数据处理开发盒，因此权宜之计优于理想的公司数据访问策略。话虽如此，最好了解如何正确执行此操作并在将来避免这种情况。

我一直试图发出一个简单的：

ALTER TABLE tablename ADD COLUMN id_col character varying (30)

在 Debian 上构建的 Postgres 9.1.13 上的 type 语句。该应用程序仍处于私人测试阶段，因此音量很低，但有些东西阻碍了这一说法。在此Postgres 锁监控帖子之后，并运行查询，

SELECT bl.pid        AS blocked_pid,
     a.usename       AS blocked_user,
     kl.pid          AS blocking_pid,
     ka.usename      AS blocking_user,
     a.current_query AS blocked_statement
 FROM  pg_catalog.pg_locks  bl
 JOIN pg_catalog.pg_stat_activity a  ON a.procpid = bl.pid
 JOIN pg_catalog.pg_locks    kl ON kl.transactionid = bl.transactionid AND kl.pid != bl.pid
 JOIN pg_catalog.pg_stat_activity ka ON ka.procpid = kl.pid
 WHERE NOT bl.granted;

不返回任何结果。

如果我跑，

SELECT * FROM pg_stat_activity

我所看到的只是ALTER TABLE带有 的语句waiting = t，以及处于空闲状态的其他几个查询。

我不是 DBA，更像是数据库开发人员，如果我遗漏了一些非常明显的东西，我深表歉意，但我从未在低容量的开发盒上看到过这样的情况，所以不知道如何继续。

我们有一个大小刚刚超过 200 GB 的数据库，包含大约 4.3 亿行、一个主键和一个空间索引。每隔几周我们就会收到一次更新，其中涉及大约 300 万行，删除一些旧功能并更新新功能。这是离线完成的。我们还有一个历史表，它存储每次更新的累积删除。该表目前大约 20 GB，40 有百万行。本质上，我们首先将更改表中标记为删除的任何内容插入到历史表中，然后从主表中删除所有内容，即删除或新建，然后将所有更改的记录（所有离线，要清楚）。

如果我在单个过程/函数中运行它，似乎会触发表重写，因为我在几个小时后回来发现它由于用完可用的磁盘空间（大约 100 GB）而失败。如果我在 psql 控制台中逐行运行它，则没有这样的问题。由于没有 DDL 语句，并且更改的行总数远小于数据库总大小，我对可能导致如此多的临时磁盘使用量的原因感到困惑，因为将整个更改记录为一个所需的总空间交易似乎要少得多。

是否有一些经验法则或一个简单的诊断查询，我可以运行它来查看发生了什么？