我正在使用基于开源 (RHEL 6.2) 的机器运行 SIEM 软件。当我运行该top命令时，我看到postgres和postmaster两者的 CPU 使用率都为 96%。有没有办法确定或查看导致这些服务堆积的原因？
假设我有一个包含工作角色的表：
CREATE TABLE roles
(
"role" character varying(80) NOT NULL,
CONSTRAINT "role" PRIMARY KEY (role)
);
假设我还有一个表、用户，并且每一行（一个特定用户）可以有任意数量的工作角色：
CREATE TABLE users
(
username character varying(12) NOT NULL,
roles character varying(80)[] NOT NULL,
CONSTRAINT username PRIMARY KEY (username)
);
我应该确保每个成员都users.roles[]存在于roles.role 中。在我看来，我想要的是对每个成员的外键约束users.roles[]，如果引用了roles.role。
这对于 postgres 似乎是不可能的。我是不是看错了？处理此问题的建议“正确”方法是什么？
我看到频繁引用WITH查询（公共表表达式，或 CTE）充当优化栅栏，服务器不允许将过滤器下推到 CTE 查询中，将公共表达式从 CTE 中拉出等。它经常被声称成为 SQL 标准要求的行为。
CTE绝对是PostgreSQL 中的优化栅栏……但这是标准要求的，还是实际上只是实现细节？
例如，这些邮件列表帖子声称或建议它是标准的：
在评论中提到它之后，我被问到它的指定位置 - 在查看了 SQL:2008 的唯一草案后，我可以访问我并没有太多运气找到它。
我还没有深入研究标准，所以我希望有人提出建议：标准实际上是否需要PostgreSQL中CTE的优化围栏？如果是这样，它在哪里指定？还是 Pg 邮件列表上的陈述有误？
另见todo list上的线程CTE优化围栏？.
根据文档，只要我没有连接到数据库，我就可以使用以下命令在控制台中删除数据库：
DROP DATABASE dbname;
或者我可以使用包装器工具删除它dropdb。
两者都给我一个错误，说数据库不存在，但是当在控制台中输入命令时\l，我得到一个数据库列表，包括我想删除的数据库。
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
---------------------------+-----------+----------+-------------+-------------+-----------------------
Blog_development | myusername | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
Blog_test | myusername | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
数据库名称是 Blog_development（以及它下面的名称）。我在玩 rails 并试图从在线文档中学习。我想重新开始并删除所有内容。
然而，当试图删除它时，它说它不存在。我是 PostgreSQL 的新手，所以我有点迷茫，除了在它不存在时弹出之外，文档中没有关于此错误的任何内容。它当然存在，它就在那里。
我正在使用psycopg2数据库 API对 PostgreSQL 9.3 进行一些工作。
我将 DB API 设置为最低隔离级别（“自动提交”模式），并直接通过 SQL 管理我自己的事务。例子：
cur = self.conn.cursor()
cur.execute("BEGIN;")
cur.execute("SELECT dbId, downloadPath, fileName, tags FROM {tableName} WHERE dlState=%s".format(tableName=self.tableName), (2, ))
ret = cur.fetchall()
cur.execute("COMMIT;")
基本上，事务是由cur.execute("BEGIN;")仅限于该游标启动的，还是针对整个连接（self.conn.cursor()）？
我正在做的一些更复杂的事情涉及多个单独的数据库操作，我在逻辑上将它们分解为函数。由于这一切都在一个将连接作为成员的类中，因此在每个函数中创建游标要方便得多。但是，我不确定在事务中创建游标是如何工作的。
基本上，如果事务是按连接进行的，我可以在事务中即时创建大量游标。如果它们是每个光标，那意味着我必须到处传递光标。是哪个？
文档没有涉及这一点，尽管您可以调用这一事实connection.commit()使我相当确信事务控制是针对每个连接的。
我正在开发一项服务，该服务依赖于用户能够接收他们自己选择的消息。这些消息在发送进行处理之前需要存储在某处。
现在我将它们存储在 postgres 数据库中，但我觉得它不能很好地扩展。
目前的布局是：
ID - MESSAGE - DATE - TIME
DATE 和 TIME 字段保存应该发送消息进行处理的时间和日期。这不能很好地扩展，好像需要在每个月的第一个星期一发送一条消息，它会占用 12 倍的空间。
问题是我似乎无法找到另一种方式来表示何时应该发送消息进行处理？理想情况下，我希望能够在一行中表示每个日期。
我们也在讨论使用 Redis，但很快就决定不使用，因为我们需要 webfrontend 的数据库。
任何人都知道如何优化消息存储？如何表示何时应该发送消息进行处理？
我也愿意就如何解决这个问题提出任何其他建议。
在 Derby（一种用 Java 编写的嵌入式数据库，主要用于测试或原型设计）中，有“freeze”和“unfreeze”命令可以在在线备份期间使用。“冻结”只会阻止所有数据库访问，直到调用“解冻”。这对于使用外部程序进行备份非常有用，如果外部程序比使用 Derby 的内部备份解决方案快得多，您可能会这样做。对于我的用例，我可以使用一些内置的文件系统实用程序几乎立即拍摄快照，因此它是一个恒定时间操作（不是O(length of DB files)）。
我正在将一个已经超过 Derby 的应用程序迁移到 PostgreSQL，我想知道那里是否有任何类似的东西可以用来停顿所有连接。另外，我更想知道我的应用程序内部的序列化点是什么，这样我就不会陷入某种尴尬的状态，因此能够暂停/恢复所有其他访问对我来说真的很不错。
由于 PostgreSQL 有一个事务日志，我可以不“冻结”就创建快照，但是快照需要通过 PostgreSQL 的恢复机制运行才能使用它，否则存储在磁盘上的内容将与我拉取的内容相同普通文件系统上的插件。这种解决方案并不理想。
编辑我了解到这pg_start_backup()是关闭的，但它不会导致传入事务阻塞，直到匹配调用pg_stop_backup()，迫使我进行时间点恢复，以pg_start_backup()返回从文件系统快照返回的事务 ID 。不必实际关闭 PostgreSQL 来获得它会很好（也许有一个伪关闭命令可以保持连接打开？）。
Ubuntu 14.04，最近安装了 Postgres 9.3。
尝试为附加的更大硬盘驱动器 (/data) 设置新的 data_directory，我更改了 postgresql.conf 文件以反映这一点。
但是，尝试重新启动服务器时出现此错误：
user@server:/etc/postgresql/9.3/main$ sudo /etc/init.d/postgresql restart
* Restarting PostgreSQL 9.3 database server
* Error: pid file is invalid, please manually kill the stale server process.
我没有太多设置 Postgres 的经验，所以我不确定从这里开始做什么，而且谷歌搜索也没有提供快速答案。
我们计划在我们的应用程序中使用 PostgreSQL，但担心崩溃安全和恢复。
我在 PostgreSQL 中找不到任何数据库崩溃恢复方法或进程。我知道 PostgreSQL 中一定有一些东西。
建议？所以如果有人能帮我找到这个，那就太好了。
主服务器中的设置：
max_wal_senders = 1 wal_level = '存档' 归档模式 = 开 存档命令 = 'cd .' wal_keep_segments = 10000
从服务器中的设置：在 recovery.conf 文件中：
待机模式 = '开' primary_conninfo = 'host=ipaddress of master user=repuser' trigger_file = '/tmp/postgresql.trigger.5432'
log_connections=on 在主服务器和从服务器上都设置
在主服务器的 pg_hba.conf 文件中为复制用户创建条目
主机复制 repuser ipaddress/32 信任
尝试复制时出现以下错误
2014-07-14 19:28:22 IST LOG：数据库系统在 2014-07-14 19:28:21 IST 的恢复中关闭 2014-07-14 19:28:22 IST 日志：进入待机模式 2014-07-14 19:28:22 IST 警告：WAL 是用 wal_level=minimal 生成的，数据可能丢失 2014-07-14 19:28:22 IST 提示：如果您临时设置 wal_level=min imal 而不进行新的基本备份，则会发生这种情况。 2014-07-14 19:28:22 IST 日志：在 0/19FFE28 达到一致恢复状态 2014-07-14 19:28:22 IST 日志：0/19FFE28 处长度为零的记录 2014-07-14 …