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
Attachments:
simplify-assert-infrastructure-1.patchtext/x-diff; charset=us-ascii; name=simplify-assert-infrastructure-1.patchDownload+24-53
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@gmail.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@gmail.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
Attachments:
v1-0001-remove-AssertArg-and-AssertState.patchtext/x-diff; charset=us-asciiDownload+162-175
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
Attachments:
assert-align-frontend.patchtext/x-diff; charset=us-asciiDownload+6-1
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.
Attachments:
0001-Make-AssertPointerAlignment-available-to-frontend-co.patchtext/plain; charset=UTF-8; name=0001-Make-AssertPointerAlignment-available-to-frontend-co.patchDownload+2-5
Peter Eisentraut <peter.eisentraut@enterprisedb.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.eisentraut@enterprisedb.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