From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fix segfault calling PQflush on invalid connection |
Date: | 2022-08-16 16:08:14 |
Message-ID: | CA+bJJby6yd4ceHCCYf26Fqbev3EYwiikdd+zav29o2d=_OXPeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Daniele:
On Mon, 15 Aug 2022 at 16:58, Daniele Varrazzo
<daniele(dot)varrazzo(at)gmail(dot)com> wrote:
> On Mon, 15 Aug 2022 at 13:21, Francisco Olarte <folarte(at)peoplecall(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2022-08-16 18:14:41 | Re: BUG #17349: Function gen_random_uuid duplicates in pgcrypto and core |
Previous Message | Bruce Momjian | 2022-08-16 15:26:47 | Re: COPY TO CSV produces data that is incompatible/unsafe for \COPY FROM CSV |