PostgreSQL
52.2. How Connections Are Established #
PostgreSQL implements a “[.quote]#process per user”# client/server model. In this model, every glossary.html#GLOSSARY-CLIENTclient process connects to exactly one glossary.html#GLOSSARY-BACKENDbackend process. As we do not know ahead of time how many connections will be made, we have to use a “[.quote]#supervisor process”# that spawns a new backend process every time a connection is requested. This supervisor process is called glossary.html#GLOSSARY-POSTMASTERpostmaster and listens at a specified TCP/IP port for incoming connections. Whenever it detects a request for a connection, it spawns a new backend process. Those backend processes communicate with each other and with other processes of the glossary.html#GLOSSARY-INSTANCEinstance using semaphores and glossary.html#GLOSSARY-SHARED-MEMORYshared memory to ensure data integrity throughout concurrent data access.
The client process can be any program that understands the PostgreSQL protocol described in Chapter 55. Many clients are based on the C-language library libpq, but several independent implementations of the protocol exist, such as the Java JDBC driver.
Once a connection is established, the client process can send a query to the backend process it’s connected to. The query is transmitted using plain text, i.e., there is no parsing done in the client. The backend process parses the query, creates an execution plan, executes the plan, and returns the retrieved rows to the client by transmitting them over the established connection.
| Prev | Up | Next |
|---|---|---|
52.1. The Path of a Query |
52.3. The Parser Stage |
Submit correction
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.
Copyright © 1996-2024 The PostgreSQL Global Development Group