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
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 multiplexingNotSupportedException.
The current workaround is to remove npgsql-Multiplexing from the connection string when passing it to the PostgresDistributedSynchronizationProvider.
If ShouldPrepareCommands could be set to false via 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?
The text was updated successfully, but these errors were encountered:
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?
Here the code is hard-coding
DatabaseConnection.ShouldPrepareCommands
to true:DistributedLock/src/DistributedLock.Postgres/PostgresDatabaseConnection.cs
Line 36 in ce4a071
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
.PostgresDistributedSynchronizationProvider
.ShouldPrepareCommands
could be set tofalse
via 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?The text was updated successfully, but these errors were encountered: