Re: [PATCH] Fix segfault calling PQflush on invalid connection
Francisco Olarte <folarte@peoplecall.com>
From: Francisco Olarte <folarte@peoplecall.com>
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs <pgsql-bugs@postgresql.org>
Date: 2022-08-16T16:08:14Z
Lists: pgsql-bugs
Daniele: On Mon, 15 Aug 2022 at 16:58, Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote: > On Mon, 15 Aug 2022 at 13:21, Francisco Olarte <folarte@peoplecall.com> wrote: > > Is there any place in the docs which states libpq just errors out ( as > > opposed to dump core ) on null PGconn? I could not find it easily, and > > I have always assumed the worst ( normally I use it wrapped, use > > nullptr as invalid marked in my data and check that (and either do > > nothing or intentionally SEGV for easier debugging ). > 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. If this is the case may be it could be documented, somewhere near the top with something like "passing a null pgconn will be treated similarly to passing a connection with BAD status". It can be a nice / simple feature and greatly simplify some use cases. Having been bitten before I normally assume only what is documented is guaranteed / reportable as a bug, and sometimes not even all of it. Francisco Olarte.
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