Repository navigation
Postgres: allow ShouldPrepareCommands to be false to work with npgsql driver Multiplexing #225
Description
Here the code is hard-coding DatabaseConnection.ShouldPrepareCommands to true:
However we have npgsql's multiplexing enabled on the connection string, which doesn't allow explicit preparation (see related comment in issue). It results in a Explicit preparation not supported with multiplexing NotSupportedException.
- The current workaround is to remove npgsql-Multiplexing from the connection string when passing it to the
PostgresDistributedSynchronizationProvider. - If
ShouldPrepareCommandscould be set tofalsevia options, then I assume we could also opt-out of the DistributedLock-multiplexing and rely on npgsql-Multiplexing instead. Do you see any issues with this?
Reacted by Rafael Kallis
Activity
madelson commentedon Jul 19, 2024
Ideally it would just work, meaning that either we always set should prepare to false for Postgres (how important is it with the current driver?) or we default it based on whether the connection is multiplexing.
That said, I’m curious as to whether distributed locking works with a multiplexed Postgres connection. Is it still able to know which session is holding the lock?
rafaelkallis commentedon Mar 3, 2025
@madelson having the option to disable prepared statements could also help in the situation where pgbouncer is used and the
max_prepared_statementsis0.See also #168 (comment) @OlegUfaev