当前位置： 首页 >
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
- 最新日志
- 热评日志
- 随机日志
- 打下时空锚点：
- 多进程旁路读取
- 确立时空锚点 (Generating the Anchor LSN) 这个锚点这么确定
- 检查点进程运行机制
- restore_command 里面的内容 详解
- pg_basebackup工具备份的时候，会不会把 服务端 表空间里面的数据备份？
- pg_basebackup备份的文件有哪些？？
- 时间点恢复过程中，recovery.singal文件没有被删除期间，数据库处于什么状态
- select pg_wal_replay_resume(); 这条命令的作用
- 库使用了自定义表空间（pg_tblspc 目录下的软链接），必须顺藤摸瓜，把那些挂载在外部 /mnt/nvme_fast/ 等目录下的真实数据文件一并打包带走！
- pg_basebackup（）原理， 这个工具的运行机制逻辑推演
- 检查点进程 在获得 wal buffer中的 lsn 和 扫描内存中的脏页的过程中，会涉及到哪些锁？？ 这些锁 的功能
- archiver进程相关
- 检查点进程的完整工作流程
- 检查点进程
- walsender（WAL 流那条，仅 -X stream）进程
- pg_basebackup进程相关
- postgresql物理备份之： 冷备份
- 关于LSN的两个问题：
- 补充： 下面的 头插法 只是针对于 找 最新的 数据库对象才成立！！！！！！
- postgresql数据库的 死锁，逻辑推导过程
- postgresql数据库–哈希表的扩容：
- PostgreSQL 内核绝对不允许跨越多个 Backend 进程来共享同一个活跃的事务 ID（XID）进行写入。这在共享内存的锁管理器和 MVCC 状态机中是物理悖论。 逻辑推导
- 确立时空锚点 (Generating the Anchor LSN) 这个锚点这么确定
- \copy工具相关
- 库使用了自定义表空间（pg_tblspc 目录下的软链接），必须顺藤摸瓜，把那些挂载在外部 /mnt/nvme_fast/ 等目录下的真实数据文件一并打包带走！
- PG 里的表级锁真的不会死锁吗？
- checkpoint机制的盲区
- 段文件的回收与删除 wal日志文件的切换