Re: fix_PGSTAT_NUM_TABENTRIES_macro patch

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Дата
Msg-id 1388706866.22946.YahooMailNeo@web125402.mail.ne1.yahoo.com
обсуждение исходный текст
Ответ на Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
The mechanism that occurs to me (and I'm not wedded to
this idea) is:

typedef uint8 T_HOFF_TYPE;
typedef struct xl_heap_header
{
        uint16          t_infomask2;
        uint16          t_infomask;
        T_HOFF_TYPE             t_hoff;
} xl_heap_header;

#define SizeOfHeapHeader        (offsetof(xl_heap_header, t_hoff) + sizeof(T_HOFF_TYPE))




On Thursday, January 2, 2014 3:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Mark Dilger <markdilger@yahoo.com> writes:
> I still don't understand why this case in src/include/pgstat.h
> is different from cases elsewhere in the code.

The reason why I'm exercised about it is that (a) somebody actually made a
mistake of this type, and (b) it wasn't caught by any automated testing.

The catalog and WAL-related examples you cite would probably crash
and burn in fairly obvious ways if somebody broke them --- for instance,
the most likely way to break SizeOfHeapHeader would be by adding another
field after t_hoff, but we'd notice that before long because said field
would be corrupted on arrival at a replication slave.

In contrast, messing up the pgstats message sizes would have no
consequences worse than a hard-to-detect, and probably platform-specific,
performance penalty for stats transmission.  So unless we think that's
of absolutely zero concern, adding a mechanism to make such bugs more
apparent seems useful.

I'm not against adding more assertions elsewhere, but it's a bit hard to
see what those asserts should test.  I don't see any practical way to
assert that field X is the last one in its struct, for instance.


            regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Store Extension Options