Обсуждение: BUG #15161: libpq - Invalid SSPI context after PQreset

The following bug has been logged on the website:

Bug reference:      15161
Logged by:          Petrovan Bogdan
Email address:      petrovanster@gmail.com
PostgreSQL version: 9.3.5
Operating system:   Windows Server 7 and 2012R2
Description:

When doing multiple parallel connects/resets I'm getting two types of
errors:

2018-04-17 00:00:21 EEST FATAL:  invalid frontend message type 112

2018-04-17 00:28:21 EEST FATAL:  could not accept SSPI security context
2018-04-17 00:28:21 EEST DETAIL:  The token supplied to the function is
invalid 

Originally this happens on a php backend. I've went "downstream" from the
php adodb library, to php_psql and then to libpq, which is the underlying
client library. 

php_psql extension does a PQreset on the connection resource.

I was able to reproduce the issue with a small C++ app:


#include "stdafx.h"
#include <libpq-fe.h>
#include <thread>

#include <iostream>

using namespace std;

void test()
{
    for (int i = 0; i < 10; i++)
    {
        PGconn* conn = PQconnectdb("hostaddr=127.0.0.1 port=5432 host=***
user=user1 dbname=db");
        auto status = PQstatus(conn);

        if (status == CONNECTION_BAD)
        {
            cout << "connection bad after connect" << endl;
        }
        PQfinish(conn);
    }
}


int main()
{
    const int N = 100;
    thread threads[N];
    for (int i = 0; i < N; i++)
    {
        threads[i] = thread(test);
    }
    for (int i = 0; i < N; i++) {
        threads[i].join();
    }
    return 0;
}


When running the application on the same machine as the postgres service, I
get the "could not accept SSPI security context" error. 

SSPI authentication host is the local computer, not an AD. 


I've tried also changing the application to run a single thread and start 10
instances of it. In this case there is no sspi error. Thus I suspect the
libpq implementation. 


Using the application above there is no "invalid frontend message type 112".
But when I add a PQreset before PQfinish (like php_pgsql ext does), it will
appear.

On 17/04/18 09:35, PG Bug reporting form wrote:
> PostgreSQL version: 9.3.5
 >
> ...
 >
> I've tried also changing the application to run a single thread and start 10
> instances of it. In this case there is no sspi error. Thus I suspect the
> libpq implementation.

The issue you're describing sounds a lot like the one that was fixed 
here: 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e6c33d594a004a2c831cdff1a16276347d30f703.

9.3.5 is a really old version. The latest 9.3 minor release is 9.3.22. 
If what you're seeing is the same bug, it has been fixed in the latest 
minor version. Even if it turns out to be something different, you 
really need to upgrade.

Note: 9.3 major version is reaching end of life in September, so you 
should start planning an upgrade to a more recent major version, too. 
See https://www.postgresql.org/support/versioning/.

- Heikki

On Tue, Apr 17, 2018 at 11:43:50AM -0400, Heikki Linnakangas wrote:
> The issue you're describing sounds a lot like the one that was fixed
> here:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e6c33d594a004a2c831cdff1a16276347d30f703.

The commit applying to REL9_3_STABLE is f2fa0c6514 to be exact (does not
really matter both are the same).

> 9.3.5 is a really old version. The latest 9.3 minor release is 9.3.22. If
> what you're seeing is the same bug, it has been fixed in the latest minor
> version. Even if it turns out to be something different, you really need to
> upgrade.

Indeed.  This smells like the same bug to me.  The error is happening on
the backend, but the frontend failed to delete properly the security
context so my bet is that doing successive connection attempts and
deletes with this version messes up with what's stored in libpq, which
induces the backend into error.
--
Michael