psqlODBC driver or MS System.Data.Odbc do not report connection lost #224

Activity

1. davecramer commented on Oct 27, 2026

   

   davecramer

   on Oct 27, 2026

   Contributor

   More actions

   Timing: probably yes. The connection is accepted and then dropped by the server, which points at server-side activity right after startup. The PostgreSQL server log at that moment is the evidence to look for: FATAL / terminating connection lines, or a postmaster restart.

   Why State stays Open: according to the code it shouldn't. We need logs to see what SQL_ATTR_CONNECTION_DEAD actually returned.

   Can you get me logs: psqlODBC MyLog and CommLog for a scenario 2 run.

   The CONNECTION_DEAD status=%d log line shows exactly what the driver told .NET.

   Possibly the server log for the same moment.

   Can you tell me: whether Windows ODBC connection pooling is enabled for the driver, their .NET version, and the connection string (especially ConnSettings).

   Whether the app shares one OdbcConnection across threads.
2. sergey-krasnogorov commented on Oct 29, 2026

   

   sergey-krasnogorov

   on Oct 29, 2026

   Author

   More actions

   Thank you for reply Dave,

   Answering your questions:
   Connection pooling is enabled for the driver, set to 60s.
   Client app is built against .NET 4.7.2.
   Connection string is widely shared in attached logs I think.
   Yes, app does share one OdbcConnection across threads but uses custom in-house implemented concurrency handling mechanism. Moreover, 'connection lost' errors occurred right after service startup/is_ready/connect, on first/second/third SELECT depending on how happy we are.

   Attached are logs we were able to collect for Scenario #2 (connection lost), but they don't tell us much. What else should be specifically configured for logging to get information we want to see there?
   I "updated" postgresql-2026-10-28_170320.log by inserting part of app log there. Seems like the server was unresponsive at that time (?)

   #224_logs_01.zip

   Best regards,
   Sergey Krasnogorov
3. davecramer commented on Nov 5, 2026

   

   davecramer

   on Nov 5, 2026

   Contributor

   More actions

   Hi Sergey,

   Thanks for the logs and the answers. Unfortunately the logs don't cover the failure:

   • mylog_EchoLoader_10820.log ends after 41 lines, while the driver is still reading the connection string. The file was last written at 16:57, and the failure in your server log is at 17:03:30, so it's from an earlier run.
   • mylog_odbcad32_28136.log and psqlodbc_odbcad32_28136.log come from the ODBC Data Source Administrator (odbcad32), not from your application.

   The server log is still useful. It shows no FATAL or terminating connection messages, so the server didn't drop your connection. And there's no new connection from your application at 17:03:30, when the SELECT failed. With connection pooling enabled, that would fit the driver manager handing your application a pooled connection that was opened before the server restarted.

   To see what happens, could you reproduce scenario 2 with the following enabled, and send the logs from that run?

   1. The driver's log (MyLog) for your application. Add Debug=1;CommLog=1 to the application's connection string, or tick MyLog and CommLog in the driver's DSN settings, and keep them on for the whole run. The driver writes mylog_EchoLoader_<pid>.log and psqlodbc_EchoLoader_<pid>.log. Please send the pair whose process ID matches the run that failed, and note the time it failed. In that log, CONNECTION_DEAD status=… lines show what the driver answered each time .NET asked whether the connection was dead.
   2. ODBC tracing, from the Tracing tab of the ODBC Data Source Administrator, for the same run. It records every call between .NET, the driver manager and the driver, including the SQLGetConnectAttr calls for SQL_ATTR_CONNECTION_DEAD (attribute 1209) and what they returned. That also shows when the driver manager takes a connection out of its pool.
   3. The PostgreSQL server log for the same period, as before.

   If you can, please also run the same test once with connection pooling turned off for the driver. If scenario 2 goes away, that tells us the stale connections are coming from the pool.

   Thanks,
   Dave