Re: fix_PGSTAT_NUM_TABENTRIES_macro patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Дата
Msg-id 17455.1388700196@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Mark Dilger <markdilger@yahoo.com>)
Список pgsql-hackers
I wrote:
> It occurs to me that, rather than trying to improve the struct definition
> methodology, maybe we should just add static asserts to catch any
> inconsistency here.  It wouldn't be that hard:

> #define PGSTAT_MAX_MSG_SIZE    1000
> #define PGSTAT_MSG_PAYLOAD    (PGSTAT_MAX_MSG_SIZE - sizeof(PgStat_MsgHdr))
> ... all else in pgstat.h as before ...

> StaticAssertStmt(sizeof(PgStat_MsgTabstat) <= PGSTAT_MAX_MSG_SIZE,
>          'bad PgStat_MsgTabstat size');
> ... and similarly for other pgstat message structs ...

After further thought it seems to me that this is a desirable approach,
because it is a direct check of the property we want, and will complain
about *any* mistake that results in too-large struct sizes.  The other
ideas that were kicked around upthread still left a lot of ways to mess up
the array size calculations, for instance referencing the wrong array
element type in the sizeof calculation.  So unless anyone has a concrete
objection, I'll go put in something like this along with Mark's fix.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE