到pg服务进程了，打算搞一个完整但简单的查询例子，从解析树到分析树到执行计划树，简论一下pg对于查询的整个处理过程（复杂点的各种树的图就太大了）。
话说pg启动后，postmaster进程进入无限循环，等待客户端请求并为之提供请求的服务（参见《pg启动过程中的那些事十七：serverloop》）。在无限循环里，postmaster进程通过调用操作系统接口select定期检查是否有客户端服务请求，如果没有，继续循环，如果有，就创建一个postgres子进程为其提供服务。
在postmaster进程的serverloop方法中，进行中无限循环等待连接请求到达。调用OS的select接口检查端口上有无请求（看和端口对应的文件句柄有什么改变），调用select后，如果有请求到达，阻塞所有信号，为服务请求完成了新建连接后，postmaster进程再次循环等待不再阻塞信号。
如果有连接请求，从socket数组ListenSocket（ListenSocket里存放的是服务器上的为socket准备的文件描述符FD）上取一个socket ListenSocket[i]，把这个socket作为参数调用ConCreate方法创建一个port结构，主要是把port结构的文件描述符设置为服务器本地对应断口的文件描述符，以及给port结构的本地和远程地址填值，如果port创建成功，调用BackendStartup(port)创建一个portgres服务进程，并把客户端进程转接到这个新创建的postgres服务进程上，以后这个进程专门为该客户端进程提供服务，然后把调用streamclose该客户端进程和postmaster进程的连接关闭，再调用ConnFree释放服务器端的port结构对象。
2
启动Postgres服务进程的调用流程图如下：
Postgres服务进程的调用流程略图
在启动进程里Main()->SubPostmasterMain()，调用了如下方法，启动XLOG后就结束了生命。
1）MemoryContextInt方法，参见《Postgresql启动过程中的那些事一》；
2）InitializeGUCOptions方法，参见《Postgresql启动过程中的那些事三》；
3）Read_backend_variablases方法，为重组BackendParameters结构读取前面存储的文件pgsql_tmp/pgsql_tmp.backend_var.[pid].[tmpFileNum]；
4）PGSharedMemoryReAttach方法，attach进程postmaster里的共享内存；
5）read_nondefault_variables方法，读非默认GUC参数，参见《Postgresql中的那些事十一：保存非默认GUC参数到文件》；
6）ClosePostmasterPorts方法，关闭“启动进程”不用的文件句柄，当然，在postmaster进程里这些文件还是打开的；
7）Securl_initialze方法，如果设置了客户端和服务器要使用SSL连接，初始化SSL 连接相关对象。pg用开源库openssl实现了相关功能，安全相关功能以后专题讨论吧，参见《pg启动过程中的那些事六》。
8）BackendInitialize方法，初始化后台进程和客户端交互的libpq协议相关实例，在port结构里设置客户端进程IP、端口等。
9）InitShmemAccess方法，在初始化本进程共享内存全局变量：这些shmem头的ShmemSegHdr、shmem起始地址ShmemBase和shmem结束地址+1的ShmemBase。定义见下面。
staticPGShmemHeader *ShmemSegHdr; /* shared mem segment header */
staticvoid *ShmemBase; /* start address of shared memory */
staticvoid *ShmemEnd; /* end+1 address of shared memory */
10）InitProcess方法，初始化一个PGPROC结构；
11）CreateSharedMemoryAndSemaphores方法，参见《Postgresql中的那些事七》；
12）BackendRun方法，为这个后台进程组织入参（一般为"postgres db_name"），然后传入PostgresMain方法。
13）PostgresMain方法是后台服务进程postgres进程的入口函数，其主要工作都在这个方法里。
SubPostmasterMain的流程图见下面。根据启动进程的传入参数“postgres –forkbackend NULL[v_AuxProcType]”走了"--forkbackend"这个分支。还有AutoVacuumLauncher进程、AutoVacuumWorker进程、归档进程、统计进程以及为前端提供服务的postgres进程等在进程初始阶段，几乎没有区别的都走了1-6步，然后根据不同入参走了不同的分支，因此以后要讨论到这些进程，就直接从这些分支开始。
SubPostmasterMain的流程图
第10步InitProcess初始化了一个每个辅助进程都有一个的PGPROC结构。每一个后台进程都在共享内存里有一个PGPROC结构，共享内存里有一个未使用的PGPROC结构链表，从其中给新的后台进程分配。参见《Postgresql启动过程中的那些事七初始化ProcGlobal》。
当等待锁时，这个PGPROC结构被链入锁的等待进程队列。回收后的PGPROC链入ProcGlobal的空闲进程列表。
注意，两阶段提交会为每一个当前已准备事务设置一个假的PGPROC。这些PGPROC出现在ProcArray数据结构里以使已准备事务显示其还在运行并且能正确显示其持有锁。已准备事务的PGPROC和真实进程的PGPROC的区别是已准备事务的PGPROC的pid等于0。在已准备事务的PGPROC里不使用信号和锁行为，但是它的myProcLocks[]列表是有效的。
struct PGPROC
{
/* proc->links必须是结构的第一个成员*/
SHM_QUEUE links; /* list link if process is in a list */
PGSemaphoreData sem; /* ONE semaphore to sleep on */
int waitStatus; /*STATUS_WAITING,STATUS_OK or STATUS_ERROR */
LocalTransactionIdlxid; /* local id of top-level transaction currently
*being executed by this proc,if running;
*else InvalidLocalTransactionId */
TransactionIdxid; /* id of top-level transaction currently being
*executed by this proc,if running and XID
*is assigned; else InvalidTransactionId */
TransactionIdxmin; /* minimal running XID as it was when we were
*starting our xact,excluding LAZY VACUUM:
*vacuum must not remove tuples deleted by
* xid>= xmin ! */
int pid; /* Backend's process ID; 0 if prepared xact */
/* 当后台进程仍在启动时这些字段是0: */
BackendId backendId; /* This backend's backend ID (if assigned) */
Oid databaseId; /* OID of database this backendis using */
Oid roleId; /* OID of role using this backend */
bool inCommit; /* true if within commit critical section */
uint8 vacuumFlags; /* vacuum-related flags,see above */
/*当是热备模式时，显示已为当前事务发出冲突信号。尽管没有要求，当持有ProcArrayLock锁事设置/消除。如果需要，没有锁可以访问。
bool recoveryConflictPending;
/* 如果有，是进程当前正在等待的轻量锁的信息 */
bool lwWaiting; /* true if waiting for an LW lock */
bool lwExclusive; /* true if waiting for exclusive access */
struct PGPROC*lwWaitLink; /* next waiter for same LW lock */
/* 如果有，进程当前正在等待的锁的信息*/
/* 如果当前没有等待的锁，waitLock和waitProcLock是NULL */
LOCK *waitLock; /* Lock object we're sleeping on ... */
PROCLOCK *waitProcLock; /* Per-holder info for awaited lock */
LOCKMODE waitLockMode; /* type of lock we're waiting for */
LOCKMASK heldLocks; /* bitmask for lock types already held on this
*lock object by this backend */
Latch procLatch; /* generic latch for process */
/*如果需要，是允许本进程等待同步复制的信息。如果没有等待的话waitLSN的值是InvalidXLogRecPtr；仅由用户后台进程设置。除非属主进程或WALSender进程可以touch syncRepState。仅当持有SyncRepLock锁时才可以用syncRepLinks。
*/
XLogRecPtrwaitLSN; /* waiting for this LSN or higher */
int syncRepState; /* wait state forsync rep */
SHM_QUEUE syncRepLinks; /* list link if process is in syncrepqueue */
/*为锁持有的所有PROCLOCK对象或者由该后台进程等待的PROCLOCK被链入这些链表中的一个，根据他们锁的分区号。
所有为持有锁或者有后台进程等待的PROCLOCK对象被链到这个列表，股他们锁的发布号。
*/
SHM_QUEUE myProcLocks[NUM_LOCK_PARTITIONS];
struct XidCache subxids; /* cache for subtransaction XIDs */
};
typedefstruct SHM_QUEUE
{
struct SHM_QUEUE *prev;
struct SHM_QUEUE *next;
} SHM_QUEUE;
第12步调用BackendRun方法，根据在客户端进程的请求，为postgres服务进程组织了入参（一般为"postgres db_name"），以这个入参调用PostgresMain方法。
第13步调用PostgresMain方法，这个方法是后台服务进程postgres进程的入口函数，其主要工作都在这个方法里。
------------ 转载请著明出处，来自博客： blog.csdn.net/beiigang beigang.iteye.com
