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
Date: Sun, 11 Jul 2021 11:28:58 -0400
Message-ID: <2468663.1626017338@sss.pgh.pa.us> (raw)
In-Reply-To: <17098-b960f3616c861f83@postgresql.org>
References: <17098-b960f3616c861f83@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, 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: <2468663.1626017338@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox