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  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Standby corruption after master is restarted
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE