中秋节假期这么快就没了，这几天还一直下雨，索性在家看看书。这次看的是Tom Lane的《A Tour of PostgreSQL Internals》。这篇小随笔就算做学习笔记了。园子里面大神多，如果有哪里讲得不对，还请各位前辈多多指教了~
在这个ppt里面，大神Tom Lane分别从三个角度对Postgresql的内部原理进行了介绍。
View 1 Postgresql进程以及内部进程间的通信
这部分比较简短，主要介绍了客户端/服务器间通信，服务器内部的通信。
1. 客户端/服务器间通信
一图胜千言，我们先上图
将上图一分为二地看，分为客户端和服务器端：
1.1 客户端
在客户端中，主要有两类进程，一个是客户端本身的应用程序(Client Application),例如：psql，这些程序向服务器端发送DB请求或者接受从服务器端返回的查询结果；
另一类是客户端接口库，主要用于处理前后端通信协议。它们是一组通信协议接口库：libpq, ODBC, JDBC,Perl DBD等等。值得一提的是，libpq是Postgresql提供的使用C语言实现的协议处理库。利用这个库可以比较轻松地和后端进行通信。除了C以外，还支持Perl和PHP等其他语言，这些语言在内部也调用了libpq。(PSQLODBC在版本09.05.0400后完全使用libpq进行前后端的通信)，当然，也有不依赖于libpq而直接与PostgreSQL通信的库。比较具有代表性的是Java, PostgreSQL的JDBC驱动是不依赖于libpq直接与PostgreSQL通信的。
1.2 服务器端
1.2.1 postmaster进程
在服务器端，postmaster是管理后端的常驻进程，默认监听UNIX Domain Socket和TCP/IP的5432端口，等待来自前端的的连接处理。一旦有前端连接过来，postgres会通过fork(2)生成子进程。对于没有fork(2)的windows平台，则利用createProcess()生成新的进程。在这种情形下，父进程的数据不会被继承过来，所以需要利用共享内存把父进程的数据继承过来。
1.2.2 postgres进程
Postgres会接受前端过来的查询，然后对数据库进行检索，最后把结果返回(select)或者对数据库进行更新（update，delete，set等）。更新的数据同时还会记录在事务日志里面（PostgreSQL称为WAL日志），这个主要是当停电的时候，服务器当机，重新启动的时候进行恢复处理的时候使用的。另外，把日志归档保存起来，可在需要进行恢复的时候使用。在PostgreSQL 9.0以后，通过把WAL日志传送其他的postgreSQL，可以实时得进行数据库复制，这就是所谓的‘数据库复制’功能。
1.2.3 其他进程
在服务端除了以上两个进程以外，还有其他很多辅助进程，这些进程都是由postmaster进程启动的。
a) Writer process
Writer process在适当的时间点把共享内存上的缓存写往磁盘。通过这个进程，可以防止在检查点的时候(checkpoint),大量的往磁盘写而导致性能恶化，使得服务器可以保持比较稳定的性能。Background writer起来以后就一直常驻内存，但是并非一直在工作，它会在工作一段时间后进行休眠，休眠的时间间隔通过postgresql.conf里面的参数bgwriter_delay设置，默认是200微秒。
这个进程的另外一个重要的功能是定期执行检查点(checkpoint)。在检查点的时候，会把共享内存上的缓存内容往数据库文件写，使得内存和文件的状态一致。这样可以在系统崩溃的时候可以缩短从WAL恢复的时间，另外也可以防止WAL无限的增长。 可以通过postgresql.conf的checkpoint_segments、checkpoint_timeout指定执行检查点的时间间隔。
b) WAL writer process
WAL writer process把共享内存上的WAL缓存在适当的时间点往磁盘写.这样可以减轻后端进程在写自己的WAL缓存时的压力，提高性能。另外，非同步提交设为true的时候，可以保证在一定的时间间隔内，把WAL缓存上的内容写入WAL日志文件。
c) Archive process
Archive process把WAL日志转移到归档日志里。如果保存了基础备份以及归档日志，即使是在磁盘完全损坏的时候，也可以回复数据库到最新的状态。
d) stats collector process
统计信息的收集进程。收集好统计表的访问次数，磁盘的访问次数等信息。收集到的信息除了能被autovaccum利用，还可以给其他数据库管理员作为数据库管理的参考信息。
e) Logger process
把postgresql的活动状态写到日志信息文件（并非事务日志），在指定的时间间隔里面，对日志文件进行rotate。
f) Autovacuum启动进程
autovacuum launcher process是依赖于postmaster间接启动vacuum进程。而其自身是不直接启动自动vacuum进程的。通过这样可以提高系统的可靠性。
g) 自动vacuum进程
autovacuum worker process进程实际执行vacuum的任务。有时候会同时启动多个vacuum进程。
h) wal sender / wal receiver
wal sender 进程和wal receiver进程是实现postgresql复制(streaming replication)的进程。Wal sender进程通过网络传送WAL日志，而其他PostgreSQL实例的wal receiver进程则接收相应的日志。Wal receiver进程的宿主PostgreSQL（也称为Standby）接受到WAL日志后，在自身的数据库上还原，生成一个和发送端的PostgreSQL(也称为Master)完全一样的数据库。
2. 服务器内部通信
还是要上图：
postmaster在接受到客户端的请求后，会创建共享内存，内存里的数据是从Unix系统硬盘里面读出来的，供postgres进程读取和写入，即客户端对postgresql数据库中的数据的操作不是实时写回物理磁盘的，而是通过Writer process定期写回磁盘，这里具体可以参照上面提到的几个进程。
为了能看得更明白一点，总结以上两点，我们来一张更细致的图，如下：
3. View 1 小结
postgresql进程间的这种机制的好处是：
- 客户端和服务器端的“硬”分离，使系统具有良好的安全性和可靠性；
- 使得Postgrsql在网络环境下能够工作良好(此处应该是指客户端接口库)；
- 在大部分Unix系统上使用方便，工作良好。
缺点也是明显的：
- 服务器内部的通信过于依赖share memory(大小是有明显限制的)，限制了其扩展性；
- postgresql的连接启动时间是一定的，对于运行时间较短的客户端任务而言，该时间开销所占比重较大。不过这个缺点通常可以通过客户端连接池的方法来解决。
这篇介绍了 《A Tour of PostgreSQL Internals》中三个View中View 1 的内容，View2 和View3我们明天再继续学习吧。
对了，附上链接，《A Tour of PostgreSQL Internals》
还有 本文也参考了Postgresql srcstructure