有没有办法按年龄或日期而不是硬编码名称指定文件来使用pg_archivecleanup命令清理WAL档案？
例如,使用以下命令非常简单:
pg_archivecleanup "C:\Program Files\PostgreSQL\9.2\data\pg_xlog" 000000010000004600000045
其中000000010000004600000045是文件名,之前创建的任何文件都将被删除.
但是,如果我想自动化该过程,必须有一种方法来按年龄/日期选择文件.
我正在阅读有关 Tarantool 的这篇文章，他们似乎说 AOF 和 WAL 日志的工作方式不同。
Tarantool：除了快照之外，它还有一个完整的 WAL（预写日志）。因此，它可以在每次开箱即用的交易后确保数据持久性。Redis：事实上，它只有快照。从技术上讲，您有 AOF（仅附加文件，所有操作都在其中写入），但它需要对其进行手动控制，包括重新启动后的手动恢复。简单地说，使用 Redis，您需要时不时地手动挂起服务器，制作快照并存档 AOF。
有人可以更清楚地解释两种策略之间的不同之处以及每种策略如何在高层次上工作。
我一直认为 Redis AOF 与 SQL 数据库事务日志的工作方式相同，例如在 Postgresql 中实现，但我可能错了。
请用简短的话解释这些过程之间的区别。官方文档没有给我任何把握=(
所有这些都用于将脏页从共享缓冲区刷新到磁盘（wal 或 db 磁盘？），但实际区别是什么？
从wal到db磁盘的写入过程进行得怎么样？
我的数据库中有一个有点大的表，我正在向其中插入新记录。随着记录数量的增加，我开始遇到问题并且无法插入。
我的 postgresql 日志文件建议我增加 WAL 大小：
[700] LOG: checkpoints are occurring too frequently (6 seconds apart)
[700] HINT: Consider increasing the configuration parameter "max_wal_size".
我使用 vim 获取了配置文件的路径=# show config_file;并进行了一些修改：
max_wal_senders = 0
wal_level = minimal
max_wal_size = 4GB
当我检查文件时，我看到了我所做的更改。
然后我尝试重新加载并重新启动数据库：（我使用 获取数据目录=# show data_directory ;）
我尝试重新加载：
pg_ctl reload -D path
server signaled
我尝试重新启动
pg_ctl restart -D path
waiting for server to shut down.... done
server stopped
waiting for server to start....
2020-01-17 13:08:19.063 EST [16913] LOG: listening …我在设置任务以初始迁移 + CDC 模式下将 RDS 数据库（PostgreSQL，引擎 10.15）中的数据迁移到 S3 存储桶时遇到问题。两个端点均已成功配置并测试。我已经创建了两次该任务，两次最多运行几个小时，第一次初始转储运行良好，并且也发生了一些增量转储，第二次仅初始转储完成并且没有增量转储在任务失败之前执行。
现在的错误消息是：
Last Error Task 'data-migration-bp-dev' was suspended after 9 successive recovery failures Stop Reason FATAL_ERROR Error Level FATAL_
但就在第一次失败之后：
Last Error An internal WAL conversational protocol error has occurred. Task error notification received from subtask 0, thread 0 reptask/replicationtask.c:2859 1020452 Error executing source loop; Stream component failed at subtask 0, component st_0_data-migration-rds-bp-dev; Stream component 'st_0_data-migration-rds-bp-dev' terminated reptask/replicationtask.c:2866 1020452 Stop Reason RECOVERABLE_ERROR Error Level RECOVERABLE
在 CloudWatch 日志中，我看到以下错误消息：
SOURCE_CAPTURE I: Streaming initiated …我试图了解我在 PostgreSQL 环境中的 wals 行为。我的沃尔玛设置是：
wal_keep_segments = 200
max_wal_size = 3GB
min_wal_size = 80MB
archive_command = 'cp %p /PostgreSQL-wal/9.6/pg_xlog/wal_archives/%f'
archive_timeout = 10
#checkpoint_flush_after = 256kB
#checkpoint_completion_target = 0.5
我的 wals 目录是/PostgreSQL-wal/9.6/pg_xlog/，我的 archives 目录是PostgreSQL-wal/9.6/pg_xlog/wal_archives。昨晚我的 wals 目录存储已满（存档目录也因为它们位于同一文件系统上）。
我的 wals 目录中现在有 211 条 wals ：
ls -l /PostgreSQL-wal/9.6/pg_xlog/ | wc -l
212
夜间运行的唯一内容只是从我们的监控代理中选择。我猜想创建 wal 是因为 archive_timeout 非常低，而它们被删除是因为 wal_keep_segments 很高。
今天早上，我将 wal_keep_segments 设置为 100，并将 archive_timeout 设置为 6 分钟。现在，设置这些设置并启动集群 wals 开关后工作正常，我没有看到创建了许多 wals。但是，旧的wals不是应该自动删除吗？我可以安全地删除档案吗？