Postmaster

This program acts as a clearing house for requests to the POSTGRES system. Frontend programs connect to the Postmaster, and postmaster forks a new backend process to handle the connection.

The postmaster also manages system-wide operations such as startup and shutdown. The postmaster itself doesn't do those operations, mind you --- it just forks off a subprocess to do them at the right times. It also takes care of resetting the system if a backend crashes. The postmaster process creates the shared memory and semaphore pools during startup, but as a rule does not touch them itself. In particular, it is not a member of the PGPROC array of backends and so it cannot participate in lock-manager operations. Keeping the postmaster away from shared memory operations makes it simpler and more reliable. The postmaster is almost always able to recover from crashes of individual backends by resetting shared memory; if it did much with shared memory then it would be prone to crashing along with the backends. When a request message is received, we now fork() immediately. The child process performs authentication of the request, and then becomes a backend if successful. This allows the auth code to be written in a simple single-threaded style (as opposed to the crufty "poor man's multitasking" code that used to be needed). More importantly, it ensures that blockages in non-multithreaded libraries like SSL or PAM cannot cause denial of service to other clients.