Re: fix_PGSTAT_NUM_TABENTRIES_macro patch - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Date
Msg-id 1388704558.83467.YahooMailNeo@web125406.mail.ne1.yahoo.com
Whole thread Raw
In response to Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
List pgsql-hackers
<div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida
Grande,sans-serif;font-size:12pt">I still don't understand why this case in src/include/pgstat.h<br />is different from
caseselsewhere in the code.  Taken from<br />src/include/access/heapam_xlog.h:<br /><br /><br />typedef struct
xl_heap_header<br/>{<br />    uint16      t_infomask2;<br />    uint16      t_infomask;<br />    uint8       t_hoff;<br
/>}xl_heap_header;<br /><br />#define SizeOfHeapHeader    (offsetof(xl_heap_header, t_hoff) + sizeof(uint8))<br /><br
/><br/><br />Now, if somebody changed t_hoff to be a uint16, that SizeOfHeapHeader<br />macro would be wrong.  Should
weput a static assert in the code for that?<br />I have no objection, but it seems you like the static assert in one
place<br/>and not the other, and (perhaps due to some incredible ignorance on my<br />part) I cannot see why.  I tried
lookingfor an assert of this kind already in<br />the code.  The use of this macro is in
src/backend/access/heap/heapam.c,<br/>but I didn't see any asserts for it, though there are lots of asserts for
other<br/>stuff.  Maybe I just didn't recognize it?<br /><br /><br />mark<br /><div class="yahoo_quoted"
style="display:block;"><br /><br /><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida
Grande,sans-serif; font-size: 12pt;"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida
Grande,sans-serif; font-size: 12pt;"><div dir="ltr"><font face="Arial" size="2"> On Thursday, January 2, 2014 2:05 PM,
TomLane <tgl@sss.pgh.pa.us> wrote:<br /></font></div><div class="y_msg_container">I wrote:<br clear="none" />>
Itoccurs to me that, rather than trying to improve the struct definition<br clear="none" />> methodology, maybe we
shouldjust add static asserts to catch any<br clear="none" />> inconsistency here.  It wouldn't be that hard:<br
clear="none"/><br clear="none" />> #define PGSTAT_MAX_MSG_SIZE    1000<br clear="none" />> #define
PGSTAT_MSG_PAYLOAD   (PGSTAT_MAX_MSG_SIZE - sizeof(PgStat_MsgHdr))<br clear="none" />> ... all else in pgstat.h as
before...<br clear="none" /><br clear="none" />> StaticAssertStmt(sizeof(PgStat_MsgTabstat) <=
PGSTAT_MAX_MSG_SIZE,<brclear="none" />>         'bad PgStat_MsgTabstat size');<br clear="none" />> ... and
similarlyfor other pgstat message structs ...<br clear="none" /><br clear="none" />After further thought it seems to me
thatthis is a desirable approach,<br clear="none" />because it is a direct check of the property we want, and will
complain<brclear="none" />about *any* mistake that results in too-large struct sizes.  The other<br clear="none"
/>ideasthat were kicked around upthread still left a lot of ways to mess up<br clear="none" />the array size
calculations,for instance referencing the wrong array<br clear="none" />element type in the sizeof calculation.  So
unlessanyone has a concrete<br clear="none" />objection, I'll go put in something like this along with Mark's fix.<div
class="yqt0876931955"id="yqtfd25444"><br clear="none" /><br clear="none" />            regards, tom lane<br
clear="none"/><br clear="none" /><br clear="none" />-- <br clear="none" />Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org"shape="rect"
ymailto="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<brclear="none" />To make changes to
yoursubscription:<br clear="none" /><a href="http://www.postgresql.org/mailpref/pgsql-hackers" shape="rect"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><brclear="none" /></div><br /><br
/></div></div></div></div></div>

pgsql-hackers by date:

Previous
From: "Erik Rijkers"
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: "Erik Rijkers"
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)