You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EventStore v1.1 included support for Postgres schemas (#182) and dynamic event stores (#184). These running instances will often share the same database connection settings, however they won't share database connections. Instead each started event store will start its own pool of database connections (user configurable) plus two other connections used for locking and subscriptions.
Sharing a pool of connections to the same database between event stores would reduce the total number of connections required.
One way this could be acheived is by specifying a connection_pool as an event store config option. By using the same name for multiple event stores we could share the pool of connections between instances.
@slashdotdash how much effort do you think this ticket is? We are running into this issue following dynamic apps, and I'm getting nervous about hitting db connection limits.
@davydog187 It might be quite a small change required.
The top-level EventStore.Supervisor is responsible for starting the main Postgrex connection process which sets the process name based on the event store's name. If a new config option was supported (connection_pool is what I initially thought of) to determine the connection process' name it would allow the process to be reused by multiple event store instances.
One caveat is that a MonitoredServer process would need to be used to start the Postgrex connection as it is problematic having multiple supervisors attempting to supervise the same named process. An intermediary process is needed to ensure a supervisor can be shutdown cleanly. Multiple supervisors linked to the same child process causes issues (see #194 for an example).
Leave it with me and I will do some investigation as this is a feature I will need in the near future.
EventStore v1.1 included support for Postgres schemas (#182) and dynamic event stores (#184). These running instances will often share the same database connection settings, however they won't share database connections. Instead each started event store will start its own pool of database connections (user configurable) plus two other connections used for locking and subscriptions.
Sharing a pool of connections to the same database between event stores would reduce the total number of connections required.
One way this could be acheived is by specifying a
connection_pool
as an event store config option. By using the same name for multiple event stores we could share the pool of connections between instances.The text was updated successfully, but these errors were encountered: