Re: partitioned tables and contrib/sepgsql - Mailing list pgsql-hackers

From Mike Palmiotto
Subject Re: partitioned tables and contrib/sepgsql
Date
Msg-id CAMN686EjceBQu5UCb=Mz8fNQQN5YSPAE5kMAY8yaher-vaV9Gg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] partitioned tables and contrib/sepgsql  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Apr 5, 2017 at 1:22 PM, Mike Palmiotto
<mike.palmiotto@crunchydata.com> wrote:
> On Wed, Apr 5, 2017 at 1:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> On 4/5/17 12:04, Tom Lane wrote:
>>>> Conclusion: Fedora's gcc is playing fast and loose somehow with the
>>>> command "#include <stdbool.h>"; that does not include the file
>>>> you'd think it does, it does something magic inside the compiler.
>>>> The magic evidently includes not complaining about duplicate macro
>>>> definitions for true and false.
>>
>>> Perhaps -Wsystem-headers would change the outcome in your case.
>>
>> Hah, you're right: with that,
>>
>> In file included from /usr/include/selinux/label.h:9:0,
>>                  from label.c:40:
>> /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include/stdbool.h:34:0: warning: "true" redefined
>>  #define true 1
>>
>> In file included from ../../src/include/postgres.h:47:0,
>>                  from label.c:11:
>> ../../src/include/c.h:206:0: note: this is the location of the previous definition
>>  #define true ((bool) 1)
>>
>> and likewise for "false".  So that mystery is explained.
>>
>> I stand by my previous patch suggestion, except that we can replace
>> the parenthetical comment with something like "(We don't care if
>> <stdbool.h> redefines "true"/"false"; those are close enough.)".
>>
>
> Sounds good. Updated patchset will include that verbiage, along with
> some regression tests for partitioned tables.

Looks like the label regression test is failing even without these changes.

Weirdly enough, this only happens in one place:

 84 SELECT objtype, objname, label FROM pg_seclabels
 85     WHERE provider = 'selinux' AND objtype = 'column' AND (objname
like 't3.%' OR objname like 't4.%');

I haven't figured out why this may be (yet), but it seems like we
shouldn't assume the order of output from a SELECT. As I understand
it, the order of the output is subject to change with changes to the
planner/configuration.

I'm going to hold the partition table regression changes for a
separate patch and include some ORDER BY fixes. Will post tomorrow

In the meantime, attached are the latest and greatest patches.

Thanks,
-- 
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PoC plpgsql - possibility to force custom or generic plan
Next
From: Andres Freund
Date:
Subject: Re: PoC plpgsql - possibility to force custom or genericplan