From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | petrovanster(at)gmail(dot)com |
Subject: | BUG #15161: libpq - Invalid SSPI context after PQreset |
Date: | 2018-04-17 13:35:06 |
Message-ID: | 152397210636.19364.8981052993657577297@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 15161
Logged by: Petrovan Bogdan
Email address: petrovanster(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-17 14:15:38 | Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE |
Previous Message | Tomas Vondra | 2018-04-17 12:11:21 | Re: Standby corruption after master is restarted |