From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17098: Assert failed on composing an error message when
 adding a type to an extension being dropped
In-reply-to: <17098-b960f3616c861f83@postgresql.org>
References: <17098-b960f3616c861f83@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 09 Jul 2021 20:00:01 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2468662.1626017338.1@sss.pgh.pa.us>
Date: Sun, 11 Jul 2021 11:28:58 -0400
Message-ID: <2468663.1626017338@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2468663.1626017338%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When trying to add to an extension a type that is already exists in the
> extension while the extension is being dropped I get a failed assertion with
> the following stack:

I think that the root issue here is that ExecAlterExtensionContentsStmt
fails to acquire any sort of lock on the extension.  Considering that
it *does* lock the object to be added/dropped, that's a rather glaring
oversight.  Fortunately it seems easily fixable ... though I wonder
how many other similar oversights we have.

However, that root issue is converted from a relatively minor bug into
a server crash because snprintf.c treats a NULL pointer passed to %s
as a crash-worthy error.  I have advocated for that behavior in the
past, but I'm starting to wonder if it wouldn't be wiser to change
over to the glibc-ish behavior of printing "(null)" or the like.
It seems like we've long since found all the interesting bugs that
the assert-or-crash behavior could reveal, and now we're down to
weird corner cases where its main effect is to weaken our robustness.

Thoughts?

			regards, tom lane