Re: [PATCH] Fix segfault calling PQflush on invalid connection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: Francisco Olarte <folarte(at)peoplecall(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [PATCH] Fix segfault calling PQflush on invalid connection
Date: 2022-08-15 15:54:01
Message-ID: 920911.1660578841@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2022-08-15 20:39:08 BUG #17588: RHEL 8 nothing provides libarmadillo.so.10 (64bit) needed by gdal-libs3x*
Previous Message Alvaro Herrera 2022-08-15 15:24:37 Re: Regression in pipeline mode in libpq 14.5