Horton

Thread

Commits

  1. Make AssertPointerAlignment available to frontend code

  2. Remove AssertArg and AssertState

  3. Simplify our Assert infrastructure a little.

  1. Simplifying our Trap/Assert infrastructure

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-09T19:51:57Z

    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

  2. Re: Simplifying our Trap/Assert infrastructure

    Nathan Bossart <nathandbossart@gmail.com> — 2022-10-09T21:01:48Z

    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

  3. Re: Simplifying our Trap/Assert infrastructure

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-09T21:08:39Z

    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

  4. Re: Simplifying our Trap/Assert infrastructure

    Nathan Bossart <nathandbossart@gmail.com> — 2022-10-09T21:29:37Z

    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

  5. Re: Simplifying our Trap/Assert infrastructure

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-10T19:20:08Z

    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

  6. Re: Simplifying our Trap/Assert infrastructure

    Nathan Bossart <nathandbossart@gmail.com> — 2022-10-12T18:36:20Z

    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

  7. Re: Simplifying our Trap/Assert infrastructure

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-10-12T19:19:17Z

    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.

  8. Re: Simplifying our Trap/Assert infrastructure

    Michael Paquier <michael@paquier.xyz> — 2022-10-27T07:23:53Z

    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

  9. Re: Simplifying our Trap/Assert infrastructure

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-10-28T07:36:23Z

    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.

  10. Re: Simplifying our Trap/Assert infrastructure

    Michael Paquier <michael@paquier.xyz> — 2022-10-31T00:04:24Z

    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

  11. Re: Simplifying our Trap/Assert infrastructure

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-10-31T09:02:35Z

    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.

  12. Re: Simplifying our Trap/Assert infrastructure

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-31T13:14:10Z

    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

  13. Re: Simplifying our Trap/Assert infrastructure

    Michael Paquier <michael@paquier.xyz> — 2022-11-01T00:30:13Z

    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