Simplifying our Trap/Assert infrastructure

I happened to notice that the Trap and TrapMacro macros defined in c.h
have a grand total of one usage apiece across our entire code base.
It seems a little pointless and confusing to have them at all, since
they're essentially Assert/AssertMacro but with the inverse condition
polarity. I'm also annoyed that they are documented while the macros
we actually use are not.

I'm also thinking that the "errorType" argument of ExceptionalCondition
is not nearly pulling its weight given the actual usage. Removing it
reduces the size of an assert-enabled build of HEAD from

$ size src/backend/postgres
text data bss dec hex filename
9065335 86280 204496 9356111 8ec34f src/backend/postgres

to

$ size src/backend/postgres
text data bss dec hex filename
9001199 86280 204496 9291975 8dc8c7 src/backend/postgres

(on RHEL8 x86_64), which admittedly is only about 1%, but it's 1%
for just about no detectable return.

Hence, I propose the attached.

regards, tom lane

On Sun, Oct 09, 2022 at 03:51:57PM -0400, Tom Lane wrote:
> I happened to notice that the Trap and TrapMacro macros defined in c.h
> have a grand total of one usage apiece across our entire code base.
> It seems a little pointless and confusing to have them at all, since
> they're essentially Assert/AssertMacro but with the inverse condition
> polarity. I'm also annoyed that they are documented while the macros
> we actually use are not.

+1, I noticed this recently, too.

> Hence, I propose the attached.

The patch LGTM. It might be worth removing usages of AssertArg and
AssertState, too, but that can always be done separately.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Sun, Oct 09, 2022 at 03:51:57PM -0400, Tom Lane wrote:
>> Hence, I propose the attached.

> The patch LGTM. It might be worth removing usages of AssertArg and
> AssertState, too, but that can always be done separately.

Something I thought about but forgot to mention in the initial email:
is it worth sprinkling these macros with "unlikely()"? I think that
compilers might assume the right thing automatically based on noticing
that ExceptionalCondition is noreturn ... but then again they might
not. Of course we're not that fussed about micro-optimizations in
assert-enabled builds; but with so many Asserts in the system, it
might still add up to something noticeable if there is an effect.

regards, tom lane

On Sun, Oct 09, 2022 at 05:08:39PM -0400, Tom Lane wrote:
> Something I thought about but forgot to mention in the initial email:
> is it worth sprinkling these macros with "unlikely()"? I think that
> compilers might assume the right thing automatically based on noticing
> that ExceptionalCondition is noreturn ... but then again they might
> not. Of course we're not that fussed about micro-optimizations in
> assert-enabled builds; but with so many Asserts in the system, it
> might still add up to something noticeable if there is an effect.

I don't see why not.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Sun, Oct 09, 2022 at 05:08:39PM -0400, Tom Lane wrote:
>> Something I thought about but forgot to mention in the initial email:
>> is it worth sprinkling these macros with "unlikely()"?

> I don't see why not.

I experimented with that, and found something that surprised me:
there's a noticeable code-bloat effect. With the patch as given,

$ size src/backend/postgres
text data bss dec hex filename
9001199 86280 204496 9291975 8dc8c7 src/backend/postgres

but with unlikely(),

$ size src/backend/postgres
text data bss dec hex filename
9035423 86280 204496 9326199 8e4e77 src/backend/postgres

I don't quite understand why that's happening, but it seems to
show that this requires some investigation of its own. So for
now I just pushed the patch as-is.

regards, tom lane

On Sun, Oct 09, 2022 at 02:01:48PM -0700, Nathan Bossart wrote:
> The patch LGTM. It might be worth removing usages of AssertArg and
> AssertState, too, but that can always be done separately.

If you are so inclined...

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 12.10.22 20:36, Nathan Bossart wrote:
> On Sun, Oct 09, 2022 at 02:01:48PM -0700, Nathan Bossart wrote:
>> The patch LGTM. It might be worth removing usages of AssertArg and
>> AssertState, too, but that can always be done separately.
>
> If you are so inclined...

I'm in favor of this. These variants are a distraction.

On Wed, Oct 12, 2022 at 09:19:17PM +0200, Peter Eisentraut wrote:
> I'm in favor of this. These variants are a distraction.

Agreed, even if extensions could use these, it looks like any
out-of-core code using what's removed here would also gain in clarity.
This is logically fine (except for an indentation blip in
miscadmin.h?), so I have marked this entry as ready for committer.

Side note, rather unrelated to what's proposed here: would it be worth
extending AssertPointerAlignment() for the frontend code?
--
Michael

On 27.10.22 09:23, Michael Paquier wrote:
> Agreed, even if extensions could use these, it looks like any
> out-of-core code using what's removed here would also gain in clarity.
> This is logically fine (except for an indentation blip in
> miscadmin.h?), so I have marked this entry as ready for committer.

committed

> Side note, rather unrelated to what's proposed here: would it be worth
> extending AssertPointerAlignment() for the frontend code?

Would there be a use for that? It's currently only used in the atomics
code.

On Fri, Oct 28, 2022 at 09:36:23AM +0200, Peter Eisentraut wrote:
> Would there be a use for that? It's currently only used in the atomics
> code.

Yep, but they would not trigger when using atomics in the frontend
code. We don't have any use for that in core on HEAD, still that
could be useful for some external frontend code? Please see the
attached.
--
Michael

On 31.10.22 01:04, Michael Paquier wrote:
> On Fri, Oct 28, 2022 at 09:36:23AM +0200, Peter Eisentraut wrote:
>> Would there be a use for that? It's currently only used in the atomics
>> code.
>
> Yep, but they would not trigger when using atomics in the frontend
> code. We don't have any use for that in core on HEAD, still that
> could be useful for some external frontend code? Please see the
> attached.

I don't think we need separate definitions for frontend and backend,
since the contained Assert() will take care of the difference. So the
attached would be simpler.

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I don't think we need separate definitions for frontend and backend,
> since the contained Assert() will take care of the difference. So the
> attached would be simpler.

WFM.

regards, tom lane

On Mon, Oct 31, 2022 at 09:14:10AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>> I don't think we need separate definitions for frontend and backend,
>> since the contained Assert() will take care of the difference. So the
>> attached would be simpler.
>
> WFM.

Thanks, fine by me.
--
Michael