BUG #15161: libpq - Invalid SSPI context after PQreset
| От | PG Bug reporting form | 
|---|---|
| Тема | BUG #15161: libpq - Invalid SSPI context after PQreset | 
| Дата | |
| Msg-id | 152397210636.19364.8981052993657577297@wrigleys.postgresql.org обсуждение исходный текст | 
| Ответы | Re: BUG #15161: libpq - Invalid SSPI context after PQreset | 
| Список | pgsql-bugs | 
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.
		
	В списке pgsql-bugs по дате отправления: