概述
进程和内存架构如下图所示：
启动PostgreSQL数据库时， 会先启动一个叫Postmaster的主进程， 还会fork出一些辅助
子进程， 这些辅助子进程各自负责一部分功能。 辅助子进程的分类如下。
- Logger（系统日志） 进程。
- BgWriter（后台写） 进程。
- WalWriter（预写式日志） 进程。
- PgArch（归档） 进程。
- AutoVacuum（系统自动清理） 进程。
- PgStat（统计信息收集） 进程。
主进程Postmaster
PostgreSQL数据库的主要功能都集中于Postgres程序， 该程序位于安装目录的bin目录下。
主进程Postmaster是整个数据库实例的总控进程， 负责启动和关闭该数据库实例。
用户可以运行postmaster、 postgres命令并加上合适的参数来启动数据库。
实际上， postmaster命令是一个指向Postgres的链接：
lrwxrwxrwx 1 root root 8 7月 8 22:35 /usr/local/pgsql/bin/postmaster -> postgres
当然， 更多的时候我们使用pg_ctl来启动数据库， pg_ctl也是通过运行postgres命令来启动数据库的， 只是它做了一些包装， 让我们更容易启动数据库。
所以， 主进程Postmaster实际上是第一个Postgres进程， 此主进程还会fork出一些与数据库实例相关的辅助子进程， 并对其进行管理。
当用户与PostgreSQL数据库建立连接时， 实际上是先与Postmaster进程建立连接， 此时， 客户端程序会发出身份验证消息给Postmaster主进程， Postmaster主进程根据消息中的信息进行客户端身份验证， 如果验证成功， Postmaster主进程会fork出一个子进程来为该连接服务。
fork出的子进程称为服务进程。
查询pg_stat_activity表时看到的PID就是这些服务进程的PID， 命令如下：
select pid,usename,client_addr,client_port from pg_stat_activity;
因为每次客户端与数据库建立连接时， PostgreSQL数据库都会启动一个服务进程来为该连接服务， 所以PostgreSQL数据库是进程架构模型， 这与MySQL数据库是不一样的，MySQL数据库每建立一个连接时启动的是一个线程， 所以MySQL数据库是线程架构模型。
当某个服务进程出现错误的时候， Postmaster主进程会自动完成系统恢复。
恢复过程中会停掉所有的服务进程， 然后进行数据库数据的一致性恢复， 等恢复完成后， 数据库才可以接受新的连接。
Logger系统日志进程
在配置文件postgresql.conf中有很多与日志相关的参数， 其中， 只有在参数logging_collect设置为“on”时， 主进程才会启动Logger辅助进程。
Logger辅助进程通过Postmaster进程、 所有服务进程及其他辅助进程收集所有的stderr输出， 并将这些输出写入日志文件中。
在postgresql.conf配置文件中则设置了日志文件的大小和存留时间。
当一个日志文件达到了配置中的大小或其他条件时， Logger就会关闭旧的日志文件， 并创建一个新的日志文件。
如果收到了装载配置文件的信号（SIGHUP） ，就会检查配置文件中的配置参数log_directory和log_fileanme与当前配置是否相同， 如果不相同则会切换日志文件并使用新的配置。
BgWriter后台写进程
在PostgreSQL中， BgWriter辅助进程是把共享内存中的脏页写到磁盘上的进程（刷盘）。
当向数据库中插入或更新数据时， 并不会马上把数据持久化到数据文件中。
这主要是为了提高插入、 更新、 删除数据的性能。
BgWriter辅助进程可周期性地把内存中的脏数据刷新到磁盘中， 刷新频率既不能太快， 也不能太慢。
如果一个数据块被改变了多次， 而此时刷新频率又太快， 那么这些改变每次都会被保存到磁盘中， 这会导致I/O次数增多。
在刷新频率太慢的情况下， 若有新的查询或更新需要使用内存来保存从磁盘中读取的数据块时， 由于没有空闲空间来存储这些数据块， 就需要把内存腾出来， 即先把一些内存中的脏页写到磁盘中， 这样就会导致查询或更新需要等更长的时间， 自然就会降低性能。
上面提到的这些机制由以“bgwriter_”开头的配置参数来控制。
WalWriter预写式日志写进程
WAL是Write Ahead Log的缩写， 中文名称为“预写式日志”。 （类比redo）
WAL日志也被简称为“xlog”（在9.6及更早版本中称为xlog）。
WalWriter进程就是写WAL日志的进程。
预写式日志的概念就是， 在修改数据之前必须把这些修改操作记录到磁盘中， 这样后面更新实际数据时就不需要实时地把数据持久化到文件中了。
如果机器突然宕机或数据库异常退出， 导致一部分内存中的脏数据没有及时地刷新到文件中， 在数据库重启后， 通过读取WAL日志把最后一部分的WAL日志重新执行一遍， 就可以将数据库恢复到宕机时的状态。
WAL日志保存在pg_xlog下。
xlog文件的默认大小是16MB， 为了满足恢复要求， 在xlog目录下会产生多个WAL日志， 这样就可以保证在宕机后， 未持久化的数据都可以通过WAL日志来恢复， 那些不需要的WAL日志会被自动覆盖。
PgArch归档进程
WAL日志会循环使用， 也就是说， 较早期的WAL日志会被覆盖。
PgArch归档进程会在覆盖前把WAL日志备份出来。
PostgreSQL从8.X版本开始提供PITR（Point-In-Time-Recovery） 技术， 通俗来讲， 就是在对数据库进行过一次全量备份后， 使用该技术将备份时间点之后的WAL日志通过归档进行备份， 使用数据库的全量备份再加上后面产生的WAL日志， 即可把数据库向前回滚到全量备份后的任意一个时间节点了。
AutoVacuum自动清理进程
在PostgreSQL数据库中， 对表进行DELETE操作后， 原有数据并不会立即被删除， 而且在更新数据时， 也并不会在原有数据上做更新， 而是会新生成一行数据，我们称之为“多版本”。
此时， 原有数据只是被标识为删除状态， 只有在没有并发的其他事务读到这些旧数据时， 才会将其清除。 这个清除工作就是由AutoVacuum进程来完成的。
PgStat统计数据收集进程
PgStat辅助进程主要做数据的统计收集工作。
收集的信息主要用于查询优化时的代价估算， 这些信息包括在一个表和索引上进行了多少次插入、 更新、 删除操作， 磁盘块读写的次数， 以及行的读次数。
系统表pg_statistic中存储了PgStat收集的各类统计信息。
共享内存
PostgreSQL启动后会生成一块共享内存， 共享内存主要用作数据块的缓冲区， 以便提高读写性能。
WAL日志缓冲区和CLOG（Commit Log） 缓冲区也存在于共享内存中。
除此以外， 一些全局信息也保存在共享内存中， 如进程信息、 锁的信息、 全局统计信息等。
PostgreSQL 9.3之前的版本与Oracle数据库一样， 都是使用SystemⅤ类型的共享内存，但自PostgreSQL 9.3版本之后， PostgreSQL使用mmap()方式的共享内存。
使用这种共享内存的好处是无须再配置SystemⅤ共享内存的内核参数kernel.shmmax和kernel.shmall， 就能使用较大的共享内存。
共享内存中存放的内容如图所示：
本地内存
后台服务进程除访问共享内存以外， 还会申请分配一些本地内存， 以便暂存一些不需要全局存储的数据。
这些内存缓冲区主要有以下几个：
- 临时缓冲区： 用于访问临时表的本地缓冲区。
- work_mem： 内部排序操作和Hash表在使用临时磁盘文件之前使用的内存缓冲区。
- maintenance_work_mem： 在维护性操作（比如VACUUM、 CREATE INDEX和ALTER TABLE ADD FOREIGN KEY等） 中使用的内存缓冲区。
