DisconnectionError: error with no message from the libpq

[Laura Czajkowski]

https://lp-oops.canonical.com/oops/?oopsid=OOPS-0003551dc4b1aada11ed4bc64b29e5ee

DisconnectionError: error with no message from the libpq

    Traceback (most recent call last):
  Module zope.publisher.publish, line 128, in publish
    publication.beforeTraversal(request)
  Module lp.services.webapp.publication, line 307, in beforeTraversal
    principal = self.getPrincipal(request)
  Module lp.services.webapp.publication, line 343, in getPrincipal
    principal = auth_utility.authenticate(request)
  Module lp.services.webapp.authentication, line 147, in authenticate
    return self._authenticateUsingCookieAuth(request)
  Module lp.services.webapp.authentication, line 89, in _authenticateUsingCookieAuth
    authdata = session['launchpad.authenticateduser']
  Module zope.session.session, line 433, in __getitem__
    sd = sdc[self.client_id]
  Module lp.services.webapp.pgsession, line 74, in __getitem__
    return PGSessionData(self, client_id)
  Module lp.services.webapp.pgsession, line 104, in __init__
    self.store.execute(query, (self.client_id,), noresult=True)
  Module storm.store, line 108, in execute
    return self._connection.execute(statement, params, noresult)
  Module storm.databases.postgres, line 266, in execute
    return Connection.execute(self, statement, params, noresult)
  Module storm.database, line 238, in execute
    raw_cursor = self.raw_execute(statement, params)
  Module storm.databases.postgres, line 276, in raw_execute
    return Connection.raw_execute(self, statement, params)
  Module storm.database, line 322, in raw_execute
    self._check_disconnect(raw_cursor.execute, *args)
  Module storm.database, line 376, in _check_disconnect
    raise DisconnectionError(str(exc))
DisconnectionError: error with no message from the libpq

[William Grant (wgrant)]

These are expected connection errors from fastdowntime.

[Francis J. Lacoste (flacoste)]

If those are expected, shouldn't they be swallowed? I thought that the fastdowntime connection errors were not ending in the OOPS report?

Could it be the PG update that changed disconnection error messages slightly, so that our previous filters don't work anymore?

[William Grant (wgrant)]

They're deliberately not filtered, since the ones from fastdowntime are indistinguishable from other situations where the database goes away. We want to know if the database goes away unexpectedly.