Horton

Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-13T18:26:18Z
Lists: pgsql-bugs, pgsql-hackers 
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em ter., 13 de jul. de 2021 às 11:29, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>> I think you're missing my main point, which is that it seems certain that
>> there are corner cases that do this *now*.  I'm proposing that we redefine
>> this as not being a crash case, full stop.

> I agree with Laurenz Albe, that on Debug builds, *printf with NULL, must
> crash.

Did you see my followup?  The vast majority of live systems do not do
that, so we are accomplishing nothing of value by insisting it's a
crash-worthy bug.

I flat out don't agree that "crash on debug builds but it's okay on
production" is a useful way to define this.  I spend way too much
time already on bug reports that only manifest with asserts enabled.

			regards, tom lane

Commits

  1. Make printf("%s", NULL) print "(null)" instead of crashing.

  2. Lock the extension during ALTER EXTENSION ADD/DROP.

  3. Add an assertion that we don't pass NULL to snprintf("%s").

  4. Fix broken logic for reporting PL/Python function names in errcontext.