Re: [PATCH] Fix segfault calling PQflush on invalid connection
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Cc: Francisco Olarte <folarte@peoplecall.com>,
pgsql-bugs <pgsql-bugs@postgresql.org>
Date: 2022-08-15T15:54:01Z
Lists: pgsql-bugs
Daniele Varrazzo <daniele.varrazzo@gmail.com> writes: > After exercising most of the libpq API in psycopg 3, PQflush() seems > the only one requiring a guard [1]. All the other functions seem to > behave well when passed an "invalid connection" - aka either a NULL > pointer or a connection in BAD status. I went so far as to inspect every function listed in libpq/exports.txt. All the ones that take a PGconn or PGresult check it for NULL except PQflush PQisnonblocking PQdefaultSSLKeyPassHook_OpenSSL PQisnonblocking is clearly an oversight, same as PQflush. Maybe there is a case for not bothering to check in PQdefaultSSLKeyPassHook_OpenSSL, on the grounds that you'd not get that far without a connection, but I think for consistency it should do so too. There is not a lot of consistency about whether we insist on the connection being in any particular "good" state. For some of the functions I think it's intentional that they should still work on a failed connection, but I wonder if any of those are likewise oversights. regards, tom lane
Commits
-
Add missing bad-PGconn guards in libpq entry points.
- ef9f35964dea 15.0 landed
- ee4a17e200b7 11.18 landed
- e37e9a655175 13.9 landed
- d63a69157d18 14.6 landed
- c19024d74e98 12.13 landed
- bb9237a1295a 16.0 landed
- 2a280832e1d0 10.23 landed