Simplifying our Trap/Assert infrastructure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Simplifying our Trap/Assert infrastructure
Date: 2022-10-09 19:51:57
Message-ID: 3928703.1665345117@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
simplify-assert-infrastructure-1.patch text/x-diff 5.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-10-09 21:01:48 Re: Simplifying our Trap/Assert infrastructure
Previous Message Bharath Rupireddy 2022-10-09 09:30:49 Re: ps command does not show walsender's connected db