Architecture overview

PostgreSQL usage

EventStore creates multiple connections to the Postres database:

• a pooled connection, that you configure via config/config.exs, used for most database operations (e.g. reading/appending events);
• a connection used to listen for event notifications (using Postgres' LISTEN / NOTIFY);
• and another connection for subscription advisory locks.

If you configure EventStore to use a pool_size of 10, then you will have 12 Postgres database connections in total.

The pooled connection uses :exp back-off. However the other connections use :stop back-off so that the connection process terminates when the database connection is broken. These connections are monitored by another process and will be restarted.

Why are these connections stopped on error?

Related processes need to be notified when the connection exits or is restarted. The postgrex library doesn't provide a way of being notified when the connection terminates. As an example, EventStore uses Postgres' advisory locks to guarantee only one instance of a subscription runs, regardless of how many nodes are running (or whether they are clustered). These advisory locks are tied to a database connection and are released when the connection terminates. When this happens, EventStore attempts to reacquire the locks. The EventStore.MonitoredServer module provides this process monitoring and after_exit and after_restart callback functions.