Re: Specifying the unit in storage parameter

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Specifying the unit in storage parameter
Date: 2014-08-27 11:56:46
Message-ID: CAHGQGwH30YWo-Vge5kpbVQKXSUVdRo3x-Pig7TEuyHuFuuHBbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 26, 2014 at 3:27 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Fujii Masao wrote:
>> On Thu, Aug 21, 2014 at 4:20 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>
>> > Looking at the patch, the parameter "fillfactor" in the category
>> > RELOPT_KIND_HEAP (the first element in intRelOpts of reloptions.c) is
>> > not updated with the new field. It is only a one-line change.
>> > @@ -97,7 +97,7 @@ static relopt_int intRelOpts[] =
>> > "Packs table pages only to this percentage",
>> > RELOPT_KIND_HEAP
>> > },
>> > - HEAP_DEFAULT_FILLFACTOR, HEAP_MIN_FILLFACTOR, 100
>> > + HEAP_DEFAULT_FILLFACTOR, HEAP_MIN_FILLFACTOR, 100, 0
>> > },
>>
>> Oh, good catch. I wonder why I did such a mistake...
>
> Uninitialized elements at end of struct are filled with zeroes.

Yeah, that's the reason why I could not notice the problem at compile time.

> We do
> have other examples of this -- for instance, config_generic in the guc.c
> tables are almost always only 5 members long even though the struct is
> quite a bit longer than that. Most entries do not even have "flags" set.

So you imply that the trailing zero (which the patch adds as flag)
in the reloption struct should be dropped?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-08-27 12:02:40 Simplify calls of pg_class_aclcheck when multiple modes are used
Previous Message Fujii Masao 2014-08-27 11:49:22 Re: Audit of logout