Re: fix_PGSTAT_NUM_TABENTRIES_macro patch

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Mark Dilger <markdilger(at)yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Date: 2014-01-02 23:27:21
Message-ID: 20140102232721.GE31635@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-01-02 15:15:58 -0800, Mark Dilger wrote:
> I still don't understand why this case in src/include/pgstat.h
> is different from cases elsewhere in the code.  Taken from
> src/include/access/heapam_xlog.h:
>
>
> typedef struct xl_heap_header
> {
>     uint16      t_infomask2;
>     uint16      t_infomask;
>     uint8       t_hoff;
> } xl_heap_header;
>
> #define SizeOfHeapHeader    (offsetof(xl_heap_header, t_hoff) + sizeof(uint8))
>
>
>
> Now, if somebody changed t_hoff to be a uint16, that SizeOfHeapHeader
> macro would be wrong.  Should we put a static assert in the code for that?

The reason the various SizeOfHeapHeader are written that way is that we
do not want to uselessly store trailing padding in the
WAL. E.g. sizeof(xl_heap_header) will be 6bytes, but SizeOfHeapHeader
will be 5.
I don't see an easy way to guarantee this with asserts and I think you'd
notice pretty fast if you got things wrong there because WAL replay will
just have incomplete data.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-02 23:38:08 Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Previous Message Erik Rijkers 2014-01-02 23:23:22 Re: [PATCH] Negative Transition Aggregate Functions (WIP)